fix(app): Fix entering error recovery while door is open #16245
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sfoster1
approved these changes
Sep 12, 2024
Here you go. You can still click the buttons and get the toast. 
|
mjhuff
force-pushed
the
app_recovery-door-open-splash-fix
branch
from
5ff6f52 to
c20c5f4
Compare
mjhuff
added a commit
that referenced
this pull request
Sep 16, 2024
…recovery (#16259) Closes EXEC-702 In #16245, we made sure to block an open door while on the recovery splash view, but the logic for automatically transition a run from paused -> awaiting recovery is not quite right, which results in the app seemingly automatically issuing a POST play to transition a run from a recovery paused state to awaiting recovery whenever a user opens the door during error recovery flows (ie, anywhere but the splash screen). The tricky part is that when checking the network tab, there are no POST requests to initiate the transition. This problem occurs because another app issues the POST request. The logic for dispatching this POST in the useEffect condition within RecoverySplash is to check if the error recovery wizard is active, but this doesn't account for any other app that isn't doing the recovery. The solution: if the current app displays the takeover modal (which is true for any app except the sole app controlling the robot), then don't fire the POST request.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes RABR-608
Overview
Currently, if you open the robot door while on the error recovery splash screen, the "launch recovery" button is not disabled, and the door CTA appears as soon as the user clicks "launch recovery". The pipette does not home (which isn't great), but for the most part, a user can complete recovery. However, the robot position is lost, which has downstream affects when the user either retries a failed command or resumes the protocol run, typically resulting in a
MUST_HOME_ERROR.To solve for the pipettes not homing and this downstream error, we should just block the users from entering ER until the door is closed. After testing a few different approaches, showing a warning toast seems best.
1edd67d - The fix
9261cc9 - In the low-fi days of ER designs, we had a "run paused" screen instead of the fancy splash screen. Calling that view
RunPausedSplashdoesn't make much sense anymore.Desktop
ODD
Test Plan and Hands on Testing
Changelog
Risk assessment
low