fix(api): get_slice should return last executed command if a run failed

[TamarZanzouri]

Overview

closes RQA-2243.
if a run has failed and the cursor is not supplied we should return the last executed command.

Test Plan

• Upload a json protocol that will have a failed command.

• Once run has failed fetch /runs/{runId}/commands make sure you are getting back the failed command and not the last command.

• Test python protocols as well

• Test successful protocols with and without cursor.

• Added integration tests

Changelog

• when getting command_slice check if there is a run_result (if the run ended). if it did and its in a failed status get the failed command index as the cursor.

Review requests

are you ok with this approach? is it better to store the failed command in a variable?

Risk assessment

low. should only affect failed protocols.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

❗ No coverage uploaded for pull request base (chore_release-7.2.0@ab166dc). Click here to learn what that means.

Additional details and impacted files

@@                  Coverage Diff                   @@
##             chore_release-7.2.0   #14449   +/-   ##
======================================================
  Coverage                       ?   68.07%           
======================================================
  Files                          ?     2522           
  Lines                          ?    72043           
  Branches                       ?     9223           
======================================================
  Hits                           ?    49043           
  Misses                         ?    20809           
  Partials                       ?     2191           

Flag	Coverage Δ
g-code-testing	92.43% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

[CaseyBatten]

Looks good and definitely fixes the issues faced by the current endpoint on JSON protocols. Tested on RSS Flex, performs as expected and does not raise incorrect modals in the case provided by RQA-2242.
Question below seeking some clarification:

[SyntaxColoring]

Recapping a conversation that RSS had in a call:

As-is, this PR only fixes the behavior for the current run, which is served from memory, and not for historical runs, which are served from the database. Ideally, the behavior between the two should certainly be consistent. We need to ask the app team what the priority is for solving this for historical runs.

One way to solve this for historical runs is:

• A new command status, like run-stopped-before-this-command-started. (Except with a better name.) We suspected we'd need this a while ago, in RCORE-390.
• A new database column for the command status, for efficient querying.

[SyntaxColoring]

Check out my two comments above about the target branch and historical runs, but when those are answered, this looks great to merge. Thank you!

[TamarZanzouri]

Recapping a conversation that RSS had in a call:

As-is, this PR only fixes the behavior for the current run, which is served from memory, and not for historical runs, which are served from the database. Ideally, the behavior between the two should certainly be consistent. We need to ask the app team what the priority is for solving this for historical runs.

One way to solve this for historical runs is:

• A new command status, like run-stopped-before-this-command-started. (Except with a better name.) We suspected we'd need this a while ago, in RCORE-390.
• A new database column for the command status, for efficient querying.

spoke to @shlokamin and historical runs are not urgent. will create a ticket

[sfoster1]

Looks good to me!