chore: release->edge for 8.0.0 #16389
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
… details) (#16198) On ODD Protocol Details > Deck tab, we render the protocol deck with clickable labware. Clicking a labware or stack should render the appropriate modal, whose header should be the location of that labware or stack. However, similar to how we handle this in Protocol Setup, we need to find the __initial__ locaiton of the labware at load time, rather than the final location of the labware. Here, I access that initial location to properly display the slot location icon for labware that is moved. Closes [RQA-3149](https://opentrons.atlassian.net/browse/RQA-3149)
Closes RQA-3108 (for the third time) Fixes an issue in which browser layer error messages were dropped. The app shell sends MQTT error event messages on the ALL_TOPICS topic, but browser layer callbacks do not ever subscribe to the ALL_TOPICS topic, just their individual topic. This means when the app receives a disconnect event that is applicable to all topics, those topics do not default back to polling.
…eating Quick Transfer protocols. (#16203)
* fix(app): scrolling issue in deck hardware screen
We were defaulting the liquids-confirmed state to true if there weren't any liquids, but we can only know there aren't any liquids if we've actually received an analysis that says that - until then, we shouldn't show anything at all. Make the liquids-confirmed state always be false until we get an analysis, and only _then_ set it to true if we don't have any. Closes RQA-3157
…6216) Closes RQA-3155 If you throw an estop event during pipette or gripper calibration flows, the "exit" button in the modal header does not properly fire the onClose event, making it impossible to exit the modal. Currently, onClose requires the home command to succeed in order to close the modal. Instead, let's just make the modal close regardless of whether the home command succeeds or fails. Note that module calibration flows already have this logic, it's just these two flows that don't.
…tocols (#16171) Closes RQA-3118 # Overview The check for matching RTPs had a bug where if a protocol had no RTPs, it would deem that protocol to have 'no previously matching analyses' and hence would always re-analyze the protocol, even when the protocol has not changed. This PR fixes that check and adds tests so that we'll know if it happens again. Fixing this bug revealed another bug that the legacy context plugin task being created while setting up the protocol runner, was never being stopped/ cancelled, hence preventing the server from shutting down. To fix that, I am stopping the orchestrator when the analyzer's destructor is called. ## Test Plan and Hands on Testing Follow the instructions in the RQA ticket above and see that the erroneous behavior is not seen. ## Review requests - check that the tests cover all cases of analyzing RTP & non-RTP protocols with various combinations of new and previous parameters (if any) ## Risk assessment Medium. Bug fix, but need to make sure that all combinations of possible protocol analysis params are covered. Also affects server shutdown. --------- Co-authored-by: Josh McVey <josh.mcvey@opentrons.com>
…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 <seth@opentrons.com>
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. -->
Incorporates fixups as best I could.
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.
This is the mergeback for release 8.0.0 to edge.
Process:
edgeinto this branch and handle conflictsThen merge into edge.