Chore Release 8.0.0 #15880
Merged
Chore Release 8.0.0 #15880
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
Here, I create api-client functions and types for downloading CSV file
content from the robot server's `dataFiles/{fileId}/download` endpoint.
I also add a react-api-client wrapper hook and implement in the
`HistoricalProtocolRunDrawer` component.
…r cloning an active run. (#15864)
There's a lot of places in the ODD that return either an InProgressModal or a SimpleWizardBody. This used to be fine because the InProgressMOdal had sizing, but now it doesn't so that it can be used inside other components, so those places all have an in-progress modal collapsed on top of the spinner icon. To fix this, let's make a component that is explicitly "InProgressModal designed to work alongside SimpleWizardBody", defined in SimpleWizardBody. We can make sure it's the same by splittin SWB into a container component and a contents component, and reusing the container. The container is also where styleprops go. Finally, take all the component that return (cond ? <InProgressModal /> : <SimpleWizardBody>...</SimpleWizardBody) and make them use a SimpleWizardInProgressBody instead of an InProgressModal. Since the SimpleWizardInProgressBody uses the same sizing as the SWB, the result will always be the correct size. ## Testing - [x] On the ODD, change pipette and pipette calibration have the right size spinners - [x] On the ODD, change gripper and gripper calibration have the right size spinners
…ation is flipped (#15866)
…mode in GET run by id (#15843) # Overview part of https://opentrons.atlassian.net/browse/EXEC-504. add full command error list to commands state. add whether the run has entered recovery mode and return it in GET /run/{runId} ## Test Plan and Hands on Testing Tested on dev server, Should test on a robot as well. - manually raise `TipNotAttachedError` from pickup tip command. - posted a protocol with a pickup tip command. - GET `/run/{runId}` should return the full error list in the response. `{ "data": { "id": "2a3375f6-0773-445f-aefd-2108bc7d376e", "ok": true, "createdAt": "2024-07-31T13:36:25.543796+00:00", "status": "stopped", "current": true, "actions": [ { "id": "3a3204f0-a8f0-4fbf-a5c3-19261f7a465f", "createdAt": "2024-07-31T13:36:39.326489+00:00", "actionType": "play" }, { "id": "6d66da93-fddb-4a9d-a4e1-5966158c1945", "createdAt": "2024-07-31T13:37:18.836018+00:00", "actionType": "resume-from-recovery" }, { "id": "8a54bc88-e5f3-48bc-ba80-411f2870515d", "createdAt": "2024-07-31T13:37:54.278171+00:00", "actionType": "stop" } ], "errors": [], "hasEverEnteredErrorRecovery": true, "pipettes": [ { "id": "2a652542-3b81-4c03-8a60-d3f7c33cb5b1", "pipetteName": "p1000_single_flex", "mount": "left" } ], "modules": [], "labware": [ { "id": "562293ac-6120-4bdb-9a0f-3a2736c4dae3", "loadName": "opentrons_flex_96_tiprack_50ul", "definitionUri": "opentrons/opentrons_flex_96_tiprack_50ul/1", "location": { "slotName": "C2" } }, { "id": "5e7c2ff5-46dd-443c-abff-f4e2c2e82473", "loadName": "opentrons_96_wellplate_200ul_pcr_full_skirt", "definitionUri": "opentrons/opentrons_96_wellplate_200ul_pcr_full_skirt/2", "location": { "slotName": "C3" } } ], "liquids": [], "labwareOffsets": [], "runTimeParameters": [], "protocolId": "b93d9f73-bb43-4c57-ba2c-16aedc36d06f", "completedAt": "2024-07-31T13:37:54.295804+00:00", "startedAt": "2024-07-31T13:36:39.330993+00:00" } }` ## Changelog - every `FailCommandAction` will now append the `ErrorOccurenece` to the full error list. - set state has_entered_error_recovery to True when issuing a `ResumeFromRecoveryAction`. - `StateSummery` will get hasEverEnteredErrorRecovery. - `hasEverEnteredErrorRecovery` added the `BadRun` and `Run` result. - `hasEverEnteredErrorRecovery` added to ts LegacyRun ## Review requests changes make sense? ## Risk assessment low. should not effect existing code. --------- Co-authored-by: Max Marrone <[email protected]> Co-authored-by: Seth Foster <[email protected]>
From both `ChooseRobotToRunProtocolSlideout` and `ChooseProtocolSlideout` components, we render a hook `useCreateRunFromProtocol`, which synchronously handles posting to /protocols and /runs. This PR fixes a bug where `runTimeParameterFiles` overrides were being passed to /protocols, but not to /runs in this hook.
…15874) * refactor(protocol_designer): move Slideout from atoms to components
This is a recommendation from hardware that will make sure that liquid will properly blow out even if it's significantly viscous. - [x] do a DTWiz and make sure we use the slow blowout and prepare to aspirate Closes EXEC-181
Closes RQA-2886 After clicking "return to dashboard" on the ODD, the run context is closed, and then a navigate to dashboard is issued. However, the top level redirects logic keeps the ODD on the runs summary page as long as there is an active run record, which is always the case when the network request hasn't yet completed. By the time the user clicks "return to dashboard" a second time, the run has (most likely) closed, and the user can actually navigate away. Unfortunately, throwing this navigate behind an onSuccess callback is insufficient, because the top level redirects hook correctly uses a different endpoint to determine whether it should redirect. To solve this, let's eagerly clear the query cache on the ODD for the run record. Any future refetches of that run record simply repopulate the cache. It's worth revisiting our approach to top level redirects in the future, but this solution is adequate for now.
refactor(app): display file name from robot-server data
remove enableCsvFile feature flag from app
Closes EXEC-636 and EXEC-637 and RQA-2900 Because ER always requires the users to go through drop tip flows, it's redundant and mildly annoying for users to see a second set of now irrelevant CTAs. Now, we only show the CTAs at the end of the run if the run did not enter error recovery (and the conditions for detecting potential tip attachment occur).
* chore: update electron-debug
…elected (#15659) disables the plus button for 8-channel 384 well selection when no starting well selected. also fixes a 384 well edge case when navigating back through the quick transfer flow - deselects all wells on 384 well selection mount to keep the the last selected index pointer in sync with the selected wells. closes RQA-2854
Closes AUTH-467 # Overview Adds auto-deletion of old data files. If the data files stored on disk exceed 50 files, then we start auto-deleting files as needed. The oldest file which is not being referenced by any analysis or run in the database is deleted from disk and removed from the database ## Test Plan and Hands on Testing - Add 50 data files to the robot, use some of them in a run - Check that 50 files still exist - Add another file - Check that the oldest unused file is deleted (pro-tip: you can change the file limit in robot settings for testing) ## Changelog - added `DataFileAutoDeleter` and `DataFileDeletionPlanner` - updated data file router to use auto-deletion before adding a new file - added new `remove()` method to `DataFilesStore` ## Review requests - Usual code review ## Risk assessment Medium. Doesn't change existing infrastructure, except that if implemented incorrectly, could delete data files unexpectedly.
…15871) Closes EXEC-605 This PR adds something between a feature and a bug fix. Earlier, we added rough support for a "submap", which is basically a way to get more granular routing when necessary. So for example, if you have an error recovery route and step, you could have a sub route and sub step. The idea is this would probably be necessary at some point when we had multiple apps looking at the same exact thing at the same time, but it wouldn't be needed for this release. Turns out we needed it this release in exactly one case. When we do drop tip wizard within error recovery, we effectively go to the "drop tip route" and the "before beginning" or "drop tip" or "blowout" step. When the door opens, we change the route and step to the door route and step, but when we navigate back to where we were after resuming the door open event, we effectively end up back at the start of the flows, because error recovery can't exactly pinpoint where we are in the drop tip flow. What we really need is something roughly equivalent to (for example) "recovery-drop-tip/recovery-blowout/drop-tip-flow-blowout/drop-tip-flow-jog-to-position" in order to retain the routing correctly. This is the perfect spot for using a submap!
y3rsh
added
DO NOT MERGE
…ummary` (#16223) Closes RQA-3159 Fixes the run status changing to gray when clicking "return to dashboard" on the ODD RunSummary page. The run status graying on button click has always been in the code, but because we used to navigate immediately after clicking "return to dashboard", this wasn't a user-visible problem.
…16228) there are several combinations of labware, fixtures, and modules in A1 and B1 that generate two conflicts with a configured thermocycler. this PR filters out one of 2 conflicts from display when both conflicts are with single slot labware in a protocol. other scenarios should be covered by the modules or fixtures lists. closes RQA-3112
## Cherrypick in #16208 Co-authored-by: Seth Foster <[email protected]>
Closes RABR-608 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.
<!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview If you try to do a multi-aspirate or try to do an air-gap after aspirating it throws an error so just don't do the automatic lld if there's already liquid in the tip. Still will raise an error if you call the explicit lld methods. <!-- Describe your PR at a high level. State acceptance criteria and how this PR fits into other work. Link issues, PRs, and other relevant resources. --> ## Test Plan and Hands on Testing <!-- Describe your testing of the PR. Emphasize testing not reflected in the code. Attach protocols, logs, screenshots and any other assets that support your testing. --> ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. -->
<!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview In hardware testing we were explicitly calling liquid_probe with a defined probe, but the protocol engine wasn't doing this and it was always defaulting to just the A1 nozzle. The expected behavior is that both sensors should work in an OR configuration. This just adds a check that if the # of nozzles > 1 to turn both on instead of just the A1 sensor. <!-- Describe your PR at a high level. State acceptance criteria and how this PR fits into other work. Link issues, PRs, and other relevant resources. --> ## Test Plan and Hands on Testing <!-- Describe your testing of the PR. Emphasize testing not reflected in the code. Attach protocols, logs, screenshots and any other assets that support your testing. --> ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. -->
…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.
… 96ch and update press distance (#16248) Covers RABR-617 Disables the tip presence sensor when the 96ch pipette is in single tip pickup configuration, change the press distance values down to 10.5mm
…k conflict check (#16268) Closes RQA-3175 # Overview There was a bug in the deck conflict checker that it wasn't considering the change in critical point of pipette in use when addressing reservoirs. This was leading to incorrect conflict checks when moving to any labware that had the `centerMultichannelOnWells` quirk. This PR fixes that by correctly finding the pipette's boundaries when its *critical point* is moved to the destination in question rather than its primary nozzle (the default critical point). ## Test Plan and Hands on Testing - Added integration tests that uses reservoirs with row and channel configurations - Existing unit and integration tests should remain unaffected - [x] Add tests for conflict checks with 8-channel pipette partial column configuration - [x] Test on a robot that existing pipette movements with different pipettes in different configurations is not affected ## Review requests - Make sure the logic checks out & test on robot ## Risk assessment Low. We have quite good test coverage for a lot of cases so any unexpected changes should get caught in the tests easily.
…16280) One more quick transfer test! This tests all of the advanced settings page copy and disabled states.
<!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview fix protocol summary text wrapping issue on ODD ### before  ### after  <!-- Describe your PR at a high level. State acceptance criteria and how this PR fits into other work. Link issues, PRs, and other relevant resources. --> ## Test Plan and Hands on Testing <!-- Describe your testing of the PR. Emphasize testing not reflected in the code. Attach protocols, logs, screenshots and any other assets that support your testing. --> ## Changelog - add text overlapping style to ODD <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment low <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. -->
# Overview `8.0.0_release_notes_final_final(2).md` ## Test Plan and Hands on Testing n/a ## Changelog - 3 new known issues for: - https://opentrons.atlassian.net/browse/RQA-2933 - https://opentrons.atlassian.net/browse/EXEC-660 - https://opentrons.atlassian.net/browse/RQA-3129 - wording change per resolution of discussion on #16182 ## Review requests The @y3rsh seal of approval. ## Risk assessment none.
## Overview This is the error message fix part of RQA-3171. ## Changelog When we're not ready to do a `liquidProbe`, be a little bit finer-grained about why we're not ready. Give the "missing tip" case and "plunger not ready" case their own error messages.
Closes RQA-3213 Before the network request completes when entering ER the 2nd time + in a run, useCurrentlyRecoveringFrom uses stale data. If the command that failed previously is the same command that failed currently, this gives it a flickering effect of "correct error, wrong error, correct error", but the stale data is more noticeable if you previously failed a command that wasn't the same kind as the current failure. To fix, let's just clear the query cache when we first enter recovery.
Accidentally added this command to the droptip wizard for ot-2 also, can't be there. ## testing - [x] run a drop tip with blowout from instrument panel -~[ ] run a drop tip with blowout from post-protocol~ - ~[ ] run a drop tip with blowout from post-protocol after forcing a limit switch hit~ Closes RQA-3228
… 3 nozzle (#16312) Covers RABR-623, RABR-624 Disable tip presence sensing on the 8ch Flex pipette for Single tip configuration and for Partial Column for 1-3 tips.
# Overview Update docs and release notes to advise picking up row by row, rather than column by column, when using `SINGLE` or `PARTIAL_COLUMN` layouts. ## Test Plan and Hands on Testing - [Sandbox](http://sandbox.docs.opentrons.com/docs-and-notes-static/v2/pipettes/partial_tip_pickup.html#single-layout) - Simulated new code for constructing and using lists of custom pickup locations ## Changelog - New warnings and code snippets in single and partial column sections. - Cleaned up some incorrect or imprecise `start` and `end` values. - Added API known issue. ## Review requests - Double check my code. - Double check my real-world advice. ## Risk assessment docs only
…16338) <!-- Thanks for taking the time to open a Pull Request (PR)! Please make sure you've read the "Opening Pull Requests" section of our Contributing Guide: https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests GitHub provides robust markdown to format your PR. Links, diagrams, pictures, and videos along with text formatting make it possible to create a rich and informative PR. For more information on GitHub markdown, see: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview When looking at another bug I saw that this log was growing forever and this will eventually fill up the diskspace on the robot which is very bad. <!-- Describe your PR at a high level. State acceptance criteria and how this PR fits into other work. Link issues, PRs, and other relevant resources. --> ## Test Plan and Hands on Testing We can check that this file stays in the <1k range but honestly it would have shown up in bugs of the disk filling up. <!-- Describe your testing of the PR. Emphasize testing not reflected in the code. Attach protocols, logs, screenshots and any other assets that support your testing. --> ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> ## Review requests <!-- - What do you need from reviewers to feel confident this PR is ready to merge? - Ask questions. --> ## Risk assessment Super low risk, doesn't effect the user at all. this is just a debugging log. <!-- - Indicate the level of attention this PR needs. - Provide context to guide reviewers. - Discuss trade-offs, coupling, and side effects. - Look for the possibility, even if you think it's small, that your change may affect some other part of the system. - For instance, changing return tip behavior may also change the behavior of labware calibration. - How do your unit tests and on hands on testing mitigate this PR's risks and the risk of future regressions? - Especially in high risk PRs, explain how you know your testing is enough. -->
y3rsh
removed
DO NOT MERGE
laviera
approved these changes
Sep 26, 2024
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.
Release Tracking Branch for 8.0.0