Chore release 8.8.0 into release #20004
Open
+235,563
−57,636
Conversation
This file contains hidden or 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
…ls (#19833) # Overview When `useCommandTypeSummaries.test.tsx` fails, it emits the error ``` AssertionError: expected 'Unknown' not to be 'Unknown' ``` which is not very helpful for explaining what's wrong. (AUTH-2353) This PR adds the offending command to the error message: ``` captureImage: expected 'Unknown' not to be 'Unknown' ``` which is slightly more informative. ## Test Plan and Hands on Testing Ran `yarn vitest` locally. ## Risk assessment Low.
# Overview the p200 flow rates were arbitrarily high and relying on hw controller to slow them down this just makes them explicitly the real max flow rate.
# Overview Refactored protocol run card to reflect new start/stop button designs and chip component for run status Added camera image to indicate camera enablement on robot card Updated image gallery to reflect camera disablement ## Test Plan and Hands on Testing - Smoke tested run status chips on ABR robots that were in states `paused`, `awaiting-recovery`, `running`, `completed`, `paused`, and `not started` - Smoke tested visibility of camera icon when it was enabled ## Changelog - Run status is now a chip - special casing for resizing circle chip https://github.com/user-attachments/assets/06cb6537-474b-43dc-b82d-e6711417e638 ## Review requests - Better way to do the blinking smaller circle? The original circle is too big ## Risk assessment - We are special casing the text `Paused with error` when the robot is in error recovery. The text everywhere else (robot card) is `awaiting recovery` Closes EXEC-1953 Closes EXEC-1952
Cap the blowout flow rate for moveLiquid forms to the physical pipette maximum, regardless of how high the liquid class specifies. Closes RQA-4764
…ng tips (#19817) This PR completes the implementation of tip selection in Protocol Designer (PD) by wiring up UI so users can click, hover, and otherwise interact with tip positions. It updates both the labware components and the tip selection wizard flow to reflect selected, used, and error tip states. It also adds new types to support the new tip selection behavior. Last, it implements safety checks for physically available tip pickups (considering both the current tiprack's tip presence, and the surrounding slots' respective stack heights).
<!-- 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 adding known issue with well plate stacking to 8.6 release notes. <!-- 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: Jethary <[email protected]>
<!-- 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 Adding a few other changes I'd like to get in for PD 8.6: - include more info about lids/lid stacking - tackle some small backlog items Last TODO I'd like to get in is updating the colors of the check mark and X in the `module.md` table. Can't get this to build yet, so may revisit early next week if time. <!-- 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. -->
…era enablement (#19835) Works toward EXEC-1978 The image gallery contains media cards that contain information such as the command associated with the capture image command, the previous command, and the failed command that caused the image capture, if any. The app has no effective way to derive this information consistently and accurately, especially in instances in which the protocol run is non-deterministic. To that end, the data files table is refactored heavily. The data files table itself now contains relational data concerning the physical, saved-to-disk file. Two new tables are added, an input_data_files and output_data_files table, which provide info when a data file is used as input to a run or when a data file is generated as output to a run.
# Overview Match robot settings page to protocol set up Remove canceled run banner ## Test Plan and Hands on Testing - Smoke checked robot with canceled run and simulated app to look at robot settings page ## Changelog <img width="923" height="529" alt="Screenshot 2025-10-20 at 3 38 38 PM" src="https://github.com/user-attachments/assets/bc636144-2374-454d-8e9f-a5f7265d1d47" /> - Moved RoundTab to be a shared component since it is now being used by `RobotSettings` and `ProtocolRunDetails` ## Review requests - Each page on the settings tab looks like the text is formatted differently. Probably want to do a follow up PR to fix that at some point - <img width="928" height="508" alt="Screenshot 2025-10-20 at 10 27 33 AM" src="https://github.com/user-attachments/assets/7bdfb253-3324-49c8-a816-2864ac418fa9" /> <img width="933" height="379" alt="Screenshot 2025-10-20 at 10 27 27 AM" src="https://github.com/user-attachments/assets/7f936fff-770b-44d7-b7c7-77270cffb415" /> Closes EXEC-1860 Closes EXEC-1979 Closes EXEC-1982
…19849) This PR fixes the protocol-designer project-specific i18n config to resolve lagging and spammy console logs. The issue stems from (we think) missing translation keys for tooltips for each field for a given form type. The `saveMissing` property set to `true` (as inherited by the base config in our components project) caused this lag. Also, `debug` can safely be set to `false`, since these logs offer not much helpful information but rather clutter up the console.
This reverts commit 1cf5f5a. <!-- 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 <!-- 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. -->
…ovider` (#19851) Works towards EXEC-1978 When FileProvider is instantiated, it captures a bound method reference to FileProviderExecutor's callback. Any subsequent state changes to the FileProviderExecutor instance won't be reflected when the callback executes, since the method binding happened at instantiation time. To fix, let's just keep the run-related state on the FileProvider, since the updated instance of FileProvider is injected into PE on each run.
…a for a run (#19853) Works towards EXEC-1978 To support the camera image gallery in the app, we will need two endpoints: one that supplies camera image file metadata for a particular run, and one that allows the client to get the actual image blob. This commit addresses the former. We add a /dataFiles/{runId}/images resource which provides a list of ImageFileMetadata, containing all the data the app cares about for the image gallery.
This PR fixes a bug in which multiDispense flow rate defaults could exceed the allowed range. This stems from incorrectly using singleDispense properties in FlowRateField vs the correct multiDispense field if available. Closes RQA-4779
<!-- 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 Adding some detail (but not too much) on robot motor control to the PAPI-exclusive features section of the Flex manual. <!-- 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 Is this too many knives for users to run with? Is this the right amount of detail to cover a very complex feature in the Flex manual? <!-- - 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. -->
… higher grip point (#19857) ## Overview Closes EXEC-1987. See there for background. ## Changelog * Introduce v2 of `opentrons_tough_univeral_lid`. It's identical to v1 except that its `gripHeightFromLabwareBottom` is 5.5 mm instead of 4.7 mm. * Introduce Python Protocol API v2.28. When it loads `opentrons_tough_universal_lid`, make it load v2 by default.
Closes EXEC-1986 This commit adds support for automatically deleting output data files when a run record "ages out" of the settings-defined max run record limit. The RunAutoDeleter is injected with the DataFileAutoDeleter. The DataFileAutoDeleter deletes the data files associated with a run that is marked for deletion by the RunAutoDeleter. The DataFileAutoDeleter uses the following strategy when cleaning up data files for a particular run: - Always delete all entries from output_data_files table for the run. - Always delete all physical files in the images directory for this run, since they are currently never used as input for a run (we can always revisit this behavior if that changes). - For each output file associated with a run: if it has no entries in input_data_files table, fully remove from data_files_table and delete the physical file in the data file directory. - For each output file associated with a run: if a file has entries in input_data_files table, preserve the physical file (so the ones located in dat_dir/file_id/file) and keep entries in the input_data_files table and the data_files table.
* fix(protocol-designer): fix export button z-index
* feat(components): fix robot info label word break point issue
This fixes some UX copy. Per our UX style guide, when "set up" is used as a verb, it should be two words, not "setup."
#19852) This PR adds logic to ensure the user does not select wells in which at least one of the wells in inaccesible (either by unsafe pipette movement, or empty)
…id (#19839) Updates environment file behavior and ensures the boot id is always set when stream service restarts
… from robot (#20178) Closes RQA-4839 It's possible for users to confirm their camera preferences and "enable" the camera even if it's disconnected. There are no dire consequences for doing so, but we have room to improve this behavior on the UX side. There are a few copy errors in which we don't properly surface camera state that needed updating along the same lines.
…wout (#20181) If a user specifies 1) return tip with 2) blowout enabled 3) in a trash-like entity, we need to pass a `trash_location` Python arg accordingly.
…moving runs (#20185) Closes RABR-839 Currently, if a run is started and the 21st run is a CSV protocol, the run cannot start. Run deletion is failing with a FOREIGN KEY constraint error when auto-deleting old runs to make room for new ones. The error occurred because run_store.remove() is not deleting associations in the input_data_files_table and output_data_files_table before attempting to delete the run record in the RunAutoDeleter. To fix, we just add deletion of input and output data file associations in RunStore.remove() before deleting the run record itself. This ensures all foreign key constraints are satisfied during the deletion cascade. Note that there is currently a 1:1 relationship between input files:runs and output files: runs, and we may have to revisit this logic in the future.
* fix(app): fix quick transfer waste chute option issue
We were waiting for multiple acks from certain commands, but if those commands fail at the module's gcode parser stage (i.e. because the module isn't updated and doesn't handle that gcode) then we'll never get a second ack and we'll just wait a really long time. This is ultimately fine in that it doesn't fail the protocol, but it makes anything that uses modules that have this problem take a really really long time. ## testing - [x] on a robot with a module that doesn't handle M411, check that the module polls don't take 60 seconds to complete Closes RABR-843
* fix(app): add unit to disposal volume
…ense (#20195) # Overview We were not appending the aspirate/dispense result to the move result. This means that the engine's state was not getting updated with the current labware, so the *_while_tracking commands were not updating the pipettes current location. This means that if you did an action in labware_1, then did a aspirate/dispense_while_tracking in labware_2 and then moved back to labware_1 the engine would think that the pipettes current location was still in labware 1 and it would calculate the safe Z movement and properly use waypoints to travel back to labware_1.
* fix(app): disposal volume isn't reflected
…art of QuickTransferSummaryState (#20212) # Overview This is a type-hinting change to tell TypeScript that the `aspirateState`/`dispenseState` in `retrieveLiquidClassValues.ts` is part of `QuickTransferSummaryState`. Without this, VS Code doesn't find this file when we're looking for places that touch `.disposalVolumeDispenseSettings`, wasting a lot of time for programmers trying to find what is setting that field. Adding this annotation also helps TypeScript catch typos. For example, if this file had accidentally misspelled the field as `disposalVolumeDispenseSettingsxx`, TypeScript would now complain about it. ## Test Plan and Hands on Testing Just run CI. ## Risk assessment Very low. No functional change whatsoever.
Correctly use `set_load_module` for StateUpdate when mapping 2.13 and below PAPI load module calls
Closes RQA-4807 To denote image capture on protocol error, the HTTP API uses the `errorRecoveryCameraEnabled` field except for `GET /camera`, in which case we use `errorRecoveryEnabled`. The JS code expects the shape of the camera settings to conform to the pattern elsewhere. To keep the HTTP API and the app consistent, let's update our one usage of `errorRecoveryEnabled` to `errorRecoveryCameraEnabled`. --------- Co-authored-by: Rhyann Clarke <[email protected]>
…ount for grip point calculations (#20220) Covers RABR-840 Adjusts the baked in values for the auto sealing lid to account for the new grip point calculations.
…actured with no cameras (#20081) Adds a new `sku` argument to the script that gets called during this peripherals test phase of device QC, writes SKU to EEPROM.
# Overview picking up on Monday 11/10 with the following: - Rework Heater-Shaker to include two separate heating and shaking sections - Replace time section(s) with create_timer - Work on code samples - Pick up TC at block control ## Test Plan and Hands on Testing sandbox ## Changelog ## Review requests ## Risk assessment low --------- Co-authored-by: Edward Cormany <[email protected]>
# Overview adds a simple section to Utility Commands to show users how to take an image (and cover some optional command). ## Test Plan and Hands on Testing sandbox. ## Changelog Added a new section to Utility Commands with some very small updates to the API reference. ## Review requests I chose two optional parameters for the code sample that I thought users would use frequently without getting too complicated, but if we want the example to be slightly different that's totally fine by me. Should we link the Flex manual? You can do a lot more with the camera in 8.8 from the app/ODD; but I know we don't usually link out from the API docs. ## Risk assessment low. --------- Co-authored-by: Edward Cormany <[email protected]>
Accounts for the addition of SKU to the eeprom for units produced at factory with no cameras
# Overview tpyo fix. ## Test Plan and Hands on Testing Check words ## Changelog Typo fix, one wording change to match API docs. ## Review requests 👀 ## Risk assessment nil
# Overview Adding descriptions of available dynamic pipetting actions in API 2.27. See the changelog for a full list/description of my thoughts behind each section. ## Test Plan and Hands on Testing sandbox: https://sandbox.docs.opentrons.com/docs-dynamic-actions/v2/ ## Changelog Under **Liquid Control**: - Aspirate/Dispense by Well or Location: _describe the new ``end_location`` parameter and the difference between the two locations; include a new example with multiple location, dynamic pipetting, but keep the meniscus example simple_ - Dynamic Mix: _describe the differences between "regular" and dynamic mix; includes one example and an explanation of additional parameters that can be used to customize the mix_ Under **Labware and Deck Positions**: - Meniscus: _example of using the new ``end_location parameter to aspirate or dispense tracking the meniscus_. this *might* fit better under aspirate/dispense sections, but those sections are getting so lengthy I moved this here. I _don't_ cover the new ``target="dynamic"`` arg because per Ryan, the team would like to keep this hidden until additional testing is done. Light changes to the API ref as well. ## Review requests Are any of these Flex-specific (obviously meniscus actions are limited to Flex pipettes, but is anything else specifically blocked on the OT-2)? I don't include any warnings for new position moves for users that would move their pipettes outside of the liquid and therefore not aspirate the liquid they mean to, but we already don't explicitly warn against this in other sections. I don't provide an example of a z movement during an aspirate/dispense/mix, like Ryan has shown in all hands/on video. The aspirate and dispense sections are getting long. I'm interested in eventually adding an example of this and maybe even a gif/part of the video, but don't want to add even more text to the section. ## Risk assessment low.
# Overview Additional pages added for warning to remove waste chute before 96 ch calibration ## Test Plan and Hands on Testing - smoke on robot on app https://github.com/user-attachments/assets/6a99a747-c439-4955-8a50-58b91e1f61ca ## Changelog - fixed merge conflicts - fixed continue string copy error ## Risk assessment low
# Overview Updating versioning in API docs for 2.27. ## Test Plan and Hands on Testing ## Changelog ## Review requests ## Risk assessment low
Closes RQA-4921 In #20088, we simplified the "robot is busy" banner state in robot settings by using a simplified conditional check, useRobotIsBusy. That works great for the robot settings page, and while we tried to harmonize the "busy" state logic by extending it to the robot details page, that didn't work out as well: we want users to be able to swap/calibrate pipettes on this page while a run is being set up. It's the only way to do so on the OT-2, too, so we definitely can't block it. This PR effectively reverts the changes made in #20088 to the robot details page.
…20022) # Overview The aspirate/dispense while tracking has to propagate the right type of overpressure error.
## Overview This fixes robot-server's `/redoc` page not loading. Closes RQA-4929. ## Test Plan and Hands on Testing * [x] `make -C robot-server dev` still boots * [x] Visiting http://localhost:31950/redoc shows HTTP API documentation again ## Changelog robot-server serves documentation for its HTTP API at `/redoc`. The way that works is that FastAPI serves a minimal static HTML file that loads the [Redoc](https://github.com/Redocly/redoc) JavaScript bundle from a CDN. The JavaScript bundle then fetches `./openapi.json`, extracts information about the HTTP API, and builds the actual page. In our version of FastAPI, the Redoc CDN link is https://cdn.jsdelivr.net/npm/redoc@next/bundles/redoc.standalone.js. This started 404ing recently, for reasons that probably have to do with [the `@next` version tag being problematic](Redocly/redoc#2743), causing the `/redoc` page to just show a white screen. [Newer versions of FastAPI use `@2` instead.](fastapi/fastapi#9700) The workaround here is to override the CDN URL to `@2` [following FastAPI's recommended pattern](https://fastapi.tiangolo.com/how-to/custom-docs-ui-assets/#custom-cdn-for-javascript-and-css).
# Overview Adds a known issue (reported in [RQA-4939 ](https://opentrons.atlassian.net/browse/RQA-4939)) to the 8.8. release notes. ## Test Plan and Hands on Testing ## Changelog One-line change to the app release notes. ## Review requests Does this cover the issue? Added that we would recommend canceling, as the flow is: - error recovery _does_ launch - users can click **retry** or **cancel** - "retry" will run but never succeed - ## Risk assessment low.
# Overview adds a description of a known issue (described [here](https://opentrons.slack.com/archives/C09LFJJMUD8/p1764873415007959)) with accessing camera images during a run via USB. ## Test Plan and Hands on Testing ## Changelog one-line addition to known issues in app release notes. ## Review requests ## Risk assessment low.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
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.
8.8.0