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.

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

Merged
merged 43 commits into from
Feb 4, 2025

Conversation

jbleon95
Copy link
Contributor

@jbleon95 jbleon95 commented Feb 3, 2025

Overview

An incremental mergeback of release branch changes into edge.

Test Plan and Hands on Testing

CI

Changelog

Resolved conflicts in:

  • api/src/opentrons/protocol_engine/commands/load_labware.py
  • api/src/opentrons/protocol_engine/resources/labware_validation.py
  • api/tests/opentrons/protocol_engine/state/test_geometry_view.py
  • app/src/assets/localization/en/device_details.json
  • app/src/assets/localization/en/labware_position_check.json
  • app/src/assets/localization/en/quick_transfer.json
  • hardware-testing/hardware_testing/protocols/liquid_sense/lld_test_empty_wells.py
  • shared-data/command/schemas/11.json
  • shared-data/labware/definitions/3/opentrons_tough_pcr_auto_sealing_lid/1.json

Review requests

I checked in with everybody who touched the above, but double check those specific files.

Risk assessment

Medium-lowish.

y3rsh and others added 30 commits January 6, 2025 10:29
## 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
…g Error Recovery (#17201)

Closes RQA-3822

Adds the explicit homing command to the "no labware in jaws" option, preventing fatal errors that occur after gripper recovery involving axes with unknown positioning.
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
…ids (#17195)

Covers RQA-3819
Adds in missing valid labware parents for the TC lid
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
```
…ok" (#17261)

Closes RQA-3851

When protocol cards have not ok run data, we can't retrieve the completedAt timestamp, and the fallback has been the current date, which is confusing copy. After speaking with Design, the plan is to remove copy if we can't retrieve the completedAt timestamp.
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
Closes RQA-3870 and RQA-3871

Brings the stall/collision recovery flow in-line with designs. See the tickets for details and fixes.
…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"
/>
That PR changed the stop behavior on OT-2 to fix some bugs but the tests
didn't get changed. Fix the tests.
smb2268 and others added 11 commits January 24, 2025 17:02
<!--
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.
@jbleon95 jbleon95 requested review from a team as code owners February 3, 2025 21:21
@jbleon95 jbleon95 requested review from jerader and removed request for a team February 3, 2025 21:21
@y3rsh y3rsh added the gen-analyses-snapshot-pr Generate a healing PR if the analyses snapshot test fails label Feb 3, 2025
Copy link
Contributor

github-actions bot commented Feb 3, 2025

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]>
Copy link
Contributor

@mjhuff mjhuff left a 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!

@vegano1 vegano1 self-requested a review February 4, 2025 15:12
Copy link
Contributor

@vegano1 vegano1 left a 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.

@jbleon95 jbleon95 merged commit 2b87a7a into edge Feb 4, 2025
63 checks passed
caila-marashaj pushed a commit that referenced this pull request Feb 11, 2025
…_edge snapshots (#17409)

This PR was requested on the PR
#17408

Co-authored-by: y3rsh <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gen-analyses-snapshot-pr Generate a healing PR if the analyses snapshot test fails
Projects
None yet
Development

Successfully merging this pull request may close these issues.