Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

feat(robot-server): Return a currentlyRecoveringFrom command pointer #15198

Merged
merged 11 commits into from
May 21, 2024
Merged

feat(robot-server): Return a currentlyRecoveringFrom command pointer #15198

merged 11 commits into from
May 21, 2024

Conversation

SyntaxColoring
Copy link
Contributor

@SyntaxColoring SyntaxColoring commented May 16, 2024 •
edited
Loading

Overview

Goes towards EXEC-458.

Test plan

I'm unable to push this to a robot because of problems that appear unrelated (ModuleNotFoundError: No module named 'usb'). I think this is low-risk enough that we can get away with skipping it.

Changelog

This adds a currentlyRecoveringFrom command pointer to GET /runs and GET /maintenance_runs, adjacent to current, and wires it up to the underlying ProtocolEngine.

This does not yet send MQTT notifications for it, nor does it update the frontend code to take advantage of the new pointer. Doing those in follow-up PRs.

Review requests

API design. Is this helpful to the client? Does it have simple and maintainable semantics? The term "current command" has historically been the subject of much confusion, and I wouldn't want the same thing to happen here. Would it be better or worse to define this more literally, like mostRecentFailedProtocolCommand?

Risk assessment

Low.

@SyntaxColoring
Add recoveryTarget field.
555077b
@SyntaxColoring
Rename get_final_command() -> get_most_recently_finalized_command().
4232945 
The original name could be misread as "the final command in the run," which it is usually not.
sfoster1
sfoster1 reviewed May 17, 2024
View reviewed changes
Copy link
Member

@sfoster1 sfoster1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that “recovery target” is kind of a misleading name for this, because you might not actually be recovering from the command that gets pointed to there - it might not be recoverable, for instance, or it might already have been recovered from: if command C fails, is recovered, and the protocol succeeds, command C will continue to be the thing that gets returned.

I think this should be “lastFailedProtocolCommand” or something specific like that.

@SyntaxColoring
Copy link
Contributor Author

I think that “recovery target” is kind of a misleading name for this, because you might not actually be recovering from the command that gets pointed to there - it might not be recoverable, for instance, or it might already have been recovered from: if command C fails, is recovered, and the protocol succeeds, command C will continue to be the thing that gets returned.

I think this should be “lastFailedProtocolCommand” or something specific like that.

I spoke with @mjhuff about this, and it turns out we do not actually want command C to continue to be the thing that gets returned in this case. It's easier for the client if the return value goes back to being null after a command is recovered from.

@SyntaxColoring SyntaxColoring changed the title feat(robot-server): Return a recoveryTarget command pointer feat(robot-server): Return a currentlyRecoveringFrom command pointer May 20, 2024
@SyntaxColoring SyntaxColoring marked this pull request as ready for review May 20, 2024 22:12
@SyntaxColoring SyntaxColoring requested review from a team as code owners May 20, 2024 22:12
@SyntaxColoring SyntaxColoring requested review from brenthagen and mjhuff and removed request for a team May 20, 2024 22:12
mjhuff
mjhuff approved these changes May 20, 2024
View reviewed changes
Copy link
Contributor

@mjhuff mjhuff left a comment •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense to me. As discussed in person, we might think about extending this to other routes in the future, but /commands is as much as we need right now. Thank you for implementing this!

EDIT: I can help test tomorrow if you'd like, but code LGTM.

@SyntaxColoring SyntaxColoring merged commit 142fad6 into edge May 21, 2024
23 checks passed
@SyntaxColoring SyntaxColoring deleted the more_cursors branch May 21, 2024 16:55
ryanthecoder pushed a commit that referenced this pull request May 28, 2024
@SyntaxColoring @ryanthecoder
feat(robot-server): Return a currentlyRecoveringFrom command pointer (
193f0aa 
#15198)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@DerekMaggio DerekMaggio DerekMaggio left review comments

@sfoster1 sfoster1 sfoster1 left review comments

@mjhuff mjhuff mjhuff approved these changes

@brenthagen brenthagen Awaiting requested review from brenthagen brenthagen is a code owner automatically assigned from Opentrons/js

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@SyntaxColoring @sfoster1 @DerekMaggio @mjhuff