-
Notifications
You must be signed in to change notification settings - Fork 179
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.
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
chore(release): merge chore_release-8.3.0
into edge
#17408
Conversation
## Overview This PR is the rebased version of #17141
opentrons_simulate tries to see if any json file it can reach is a labware and load it if so. We recently changed the exceptions we raise in verify_labware_definitions if that call fails, so now instead of ignoring the file on exception opentrons_simulate raises the error through and terminates. No good! Change the exception to something a little saner and make sure we can actually ignore invalid labware files in sim. Closes RQA-3820
We pipe errors from nmcli straight to the display when we get them. NMCLI has famously awful errors. We don't want to always squash them, because they could be useful, but in the case of a mis-entered WPA2 PSK, we can be pretty sure that's the problem. This will now say "check your wifi credentials" <img width="607" alt="Screenshot 2025-01-07 at 4 46 15 PM" src="https://github.com/user-attachments/assets/d9006f01-37e8-4221-812a-900ffcb61960" /> ## Testing - [x] Connect to a wifi network and purposefully enter the wrong password; you should get a less awful message. Note that this only actually works if you're disconnected from wifi when you try to connect; if you're connected to wifi and then try and connect to a network and use the wrong password, you just don't get a result because the request went out over the original wifi network which got disconnected. It's the same code on the flex, ot-2 on the desktop (the ODD has a different message). Closes RSQ-3
Fix a flaky test by running filesystem commands sequentially instead of in parallel.
This is very odd and I'm not sure when it would have changed but this is the thing the error message says to do. ## Testing - [x] does the apple build work - [x] does the apple build run
…rotocol (#17216) <!-- 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 We're doing a direct "load_definintion" call in this protocol so we need to update it to have the new OEM arg added in 8.3 <!-- 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. -->
Came up for PD ( #17229 ), probably will come up here too. Let's get ahead of it. If the build passes this should be fine.
… can errors (#17117) <!-- 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 We occasionally get some ABR issues where the can bus says it's not receiving ACKs or that a move group says it didn't get all expected nodes, but reports [] as the missing nodes. I think the second bug is because we're checking with `if not self._moves[group_id]` instead of checking `if len(self._moves[group_id]) == 0:` Which should be equivalent but I think there may be some python cleanup bug that reports the list as true due to a remnant that hasn't been garbage collected yet. <!-- 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. -->
…ed (#17264) robot-server sometimes stores, in its database, run commands that do not have a `result`. For example, if a command failed, it has an `error` instead of a `result`. After the recent Pydantic v1->v2 upgrade, parsing these commands was broken for about 1/3rd of our command types. The server would raise a 500 error. Their Pydantic models were defined like: ``` result: Optional[FooResult] ``` In Pydantic v1, that parses JSON where `result` is `null` or omitted, but in Pydantic v2, it only parses JSON where `result` is `null`. We need to change it to: ``` result: Optional[FooResult] = None ```
This is used by the client to decide whether something is a lot when it's rendering destinations, and if this doesn't exist then intervention modals will show the labware moving off deck. Closes RQA-3839
…ction (#17316) This commit brings the `lastRunCommandPromptedErrorRecovery` util back and adds the new and improved behavior to also check if Error Recovery is enabled (in settings). If it's not enabled, we need to run tip detection even if the last run command was recoverable.
- the takeover modal for maintenance runs (RQA-3868) - run start confirmation (not tagged yet) - run cancel confirmation (RQA-3869) Closes RQA-3868 Closes RQA-3869 <img width="1046" alt="Screenshot 2025-01-17 at 4 58 05 PM" src="https://github.com/user-attachments/assets/66d00f4a-5e49-4f34-8049-ae74051f710e" /> <img width="1037" alt="Screenshot 2025-01-17 at 4 58 40 PM" src="https://github.com/user-attachments/assets/b39ef8b7-77aa-4cfe-8452-e447e439460b" /> <img width="1035" alt="Screenshot 2025-01-17 at 5 05 22 PM" src="https://github.com/user-attachments/assets/ffb47a09-0f02-4b26-b4e4-54fa43d7865c" />
<!-- 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 This just copies the updated well geometry definitions from edge over to chore_release. <!-- 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. --> Co-authored-by: Caila Marashaj <[email protected]>
…oading (#17237) Add evo tip adapter and evo tips labware definition but as a labware so that liquid handling actions can happen in the 'labware'.
Covers EXEC-907 Introduces Evotip (or resin-tip) specific commands to the instrument context. These commands achieve the desired sealing, pressurization and unsealing steps for a resin tip protocol.
…entrons into mergeback_chore_release_830_into_edge
A PR has been opened to address analyses snapshot changes. Please review the changes here: #17409 |
…_edge snapshots (#17409) This PR was requested on the PR #17408 Co-authored-by: y3rsh <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The FE resolves look good, thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Backend merges look good, also verified evotip + flex stacker changes.
…_edge snapshots (#17409) This PR was requested on the PR #17408 Co-authored-by: y3rsh <[email protected]>
Overview
An incremental mergeback of release branch changes into edge.
Test Plan and Hands on Testing
CI
Changelog
Resolved conflicts in:
Review requests
I checked in with everybody who touched the above, but double check those specific files.
Risk assessment
Medium-lowish.