Chore release 8.8.0 into release #20004
Open
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
…19754) * fix(step-generation) fix undefined issue of getFullStackFromLabwares
…dSpecs() with tiprack=null (#19760) # Overview This is fix 1/n to fix the many `Cannot read properties of null` errors when we call `matchingTipLiquidSpecs()`. This PR addresses https://opentrons-76.sentry.io/issues/6892806132?project=4509363266387968. ## Test Plan and Hands on Testing Ran `yarn vitest step-generation/ protocol-designer/` locally. Will look at results from CI test. ## Risk assessment Low.
…eck (#19768) * fix(protocol-designer): fix allow users to click all labware on the deck
* feat(app): add CodeBlock component
* fix(protocol-designer, components) fix multiple 8.6.0 DQA
* feat(app, components):Update ProtocolDetails Header
*feat(app) add the bases for Step Detail Container
… exceeding the limit (#19759) * fix(protocol-designer):fix the issue that proceed adding labware when exceeding the limit
# Overview Adds bindings for the /camera resources. ## Test Plan and Hands on Testing - Testing on future branch, right now these are not functional Closes EXEC-1835
…sualization (#19773) * feat(app, app-shell) add new item to secondary window for protocol visualization
* fix(app-shell): fix change the secondary window title
## Overview This upgrades Prettier from v2.2.1, which is ~5 years old, to v3.6.2. Unfortunately, there have been a lot of little tweaks to Prettier's style in the meantime, so this causes a big diff. ## Risk assessment Low. Nothing here should incur any behavioral change. I think the risk is really just that it might cause annoying merge conflicts for a while.
* fix(protocol-designer): Fix modify select labware modal height
First merge after Prettier upgrade in `edge`.
…error (#19785) # Overview We're getting like 100 Sentry reports per day of `UnhandledRejection: Non-Error promise rejection captured with value: Object Not Found Matching Id:..., MethodName:update, ParamCount:...` https://opentrons-76.sentry.io/issues/6805881397/?project=4509363266387968 This seems to be caused by the Microsoft Defender "Safe Links" feature that tries to run PD in a simulated browser environment to scan for malware, especially when someone mentions the PD URL in a message in Outlook. This is a widely reported issue by Sentry users, and there's nothing we can do about it besides just ignoring the error: - getsentry/sentry-javascript#3440 - https://forum.sentry.io/t/unhandledrejection-non-error-promise-rejection-captured-with-value/14062 ## Test Plan and Hands on Testing Ran PD locally. Will run CI tests. ## Risk assessment Low.
…19765) Standardize AWS role usage for static deployments Problem: Static deployment workflows (Protocol Designer, Labware Library, and Docs) were using inconsistent AWS role secrets, making role management complex and potentially causing deployment failures. Changes: Renamed DOCS_SANDBOX_ROLE to STATIC_DEPLOYMENT_ROLE across all static deployment workflows Updated Protocol Designer workflow to use the unified role instead of PD_SANDBOX_ROLE Fixed sandbox bucket name from sandbox.designer.opentrons.com to opentrons.sandbox.designer to match actual S3 bucket Updated corresponding test assertions to reflect the new bucket name Kept domain URLs unchanged (sandbox.designer.opentrons.com) as these are the user-facing URLs Files Updated: .github/workflows/pd-test-build-deploy.yaml .github/workflows/ll-test-build-deploy.yaml .github/workflows/docs-build-deploy.yaml .github/workflows/docs-build.yaml scripts/static-deploy/deploy_config.py scripts/static-deploy/tests/test_deploy_config.py scripts/static-deploy/tests/test_deploy.py Result: All static deployments now use a single, consistent AWS role (STATIC_DEPLOYMENT_ROLE), simplifying role management and ensuring proper permissions across all static site deployments. Note: The STATIC_DEPLOYMENT_ROLE secret will need to be created/updated in GitHub repository settings with the appropriate AWS role ARN.
* fix(protocol-designer) fix liquid form submit issue
* fix(protocol-designer): fix export button z-index issue
…#19787) * fix(protocol-designer) fix whitescreen issue when clicking an adapter
# Overview This essentially adds the TrackFromLocation and the TrackToLocation to the protocol engine commands. It then passes new information down to the OT3Api, replacing the Z distance with the end point, and updating the motion utilities to create the target position from that instead of z_distance. If no TrackToLocation is provided to the engine command then it preserves the old behavior where it tracks the meniscus. As is the protocol api just preserves the current behavior, hooking up the TrackToLocation with that layer is another ticket. TODO add checking that makes sure the X/Y/Z move is a valid move that can occur within the timeframe of the plunger move.
Closes EXEC-1957 For the camera work, the filename created when saving an image will require certain metadata that is not solely available to PE, but some of which is available on the robot-server, RunFileNameMetadata. The FileProviderExecutor singleton will need to set this metadata on a per-run basis and also manage cleanup of this metadata when a run is un-currented.
# Overview Robot context was incorrectly kicking back that the p200_96 was not a 96 channel when someone tried to use it for resin tips. This just centeralizes the test into validation and adds a test that iterates through all the pipette names to make sure everything is working properly now.
<!-- 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 8.8 alpha 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 Anything I'm missing? everything clear? <!-- - 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. -->
…ns (#20020) # Overview We've ended up with many definitions for the type "labware definitions by URI", including: - `LabwareDefinitionsByURI` in `getLabwareDefinitionsByURIForProtocol.ts` - `LabwareDefinitionsByUri` in `getLoadedLabwareDefinitionsByUri.ts` - `LabwareDefByDefURI` in `protocol-designer` Due to re-exports, the first 2 are exported at the top level of `@opentrons/shared-data`. I suspect that when writing code, people just click on whichever pops up first in their IDE autocomplete. They would probably be surprised at which file their import is coming from. This PR merges the first 2 definitions and moves them to `shared-data/js/types.ts`. The 3rd definition is a PD-specific alias for `LabwareDef2ByDefURI`, and this PR changes it to a proper alias. (Note that there's also `RunLoadedLabwareDefinitionsByUri`, which I'm not going to touch for now because its name is a less tempting target for autocomplete.) ## Test Plan and Hands on Testing Run CI. ## Risk assessment Low.
…erated value (#20021) Closes RQA-4813 In the desktop app's image gallery, there is an overflow menu that enables users to download a single image. Clicking that option renders an OS download dialogue and populates the filename with an app-generated filename, which follows a Design-specified naming convention. However, generating the filename on the app fails to capture the PAPI image_capture command's ability to specify a prefix to the naming convention via the filename param. The filename exists in its entirety on the server in the data files table, so let's just bubble that filename up through a few data file metadata endpoints instead of requiring the app to attempt to reflect the behavior of the server.
…king` to true (#20024) # Overview Adds `SetShakeSpeed` to heatershaker state updates Protocol analysis will now raise an error if you use `set_shake_speed` and then try to open the labware latch without deactivating the shaker first. ## Test Plan and Hands on Testing Simulated the protocol attached in the ticket, and error was raised `ProtocolCommandFailedError [line 491]: Error 4000 GENERAL_ERROR (ProtocolCommandFailedError): CannotPerformModuleAction: Heater-Shaker cannot open its labware latch while it is shaking.` <img width="921" height="488" alt="Screenshot 2025-11-04 at 12 20 44 PM" src="https://github.com/user-attachments/assets/0898ca36-b09d-4b0b-b239-f5e43659e917" /> ## Risk assessment low Closes RQA-4814
Ensure air gap aspirate and dispense in place commands in consolidate
command creator include `{ isAirGap: true }` for proper omission in
substep generation.
Closes RQA-4791
Resolved conflicts: - protocol-designer/release-notes.md
…ks (#20034) # Overview (This is Part 6 of tiprack definition fixes for PD.) The problem we're trying to solve: `Hydrated{MoveLiquid/Mix}FormData.tipRack` contains the URI of a tiprack, which could be standard or custom labware. Then the lower-level functions have to look up the tiprack definition for that URI. There are 3 ways they try to do that: 1. Get the definition from `InvariantContext.labwareEntities`. 2. Get the definition from `PipetteEntity.tiprackLabwareDef`. 3. Get it from `getAllDefinitions()[tiprackURI]`. The problem with (1) and (2) is that the tiprack is removed from `InvariantContext` and `PipetteEntity` when the user unselects a tiprack from the pipette, but a step form can still refer to the deleted tiprack's URI. The problem with (3) is that `getAllDefinitions()` only contains standard labware, and doesn't work for custom tipracks. We could solve this problem if any function could look up a tiprack definition whenever it needed to, whether the tiprack is custom or not. But PD does not make that easy. The custom tiprack definitions are available in `BaseState`, but most functions only have access to the `InvariantContext`, which does **not** have all the custom labware definitions. I think the best approach is to **hydrate the tiprack definition into the `HydratedMoveLiquidFormData/HydratedMixFormData`**. So this PR changes `.tipRack` from a URI string into a tiprack labware definition. Then any function using `Hydrated*FormData` would have the tiprack definition without having to implement its own lookup. (There is a precedent for this: we do the same thing when we hydrate `.pipette` in `Hydrated*FormData`, turning the field from a string into a `PipetteEntity`.) In order to hydrate the tiprack definition into `Hydrated*FormData.tipRack`, we need to pass the labware definitions down to the hydration functions, which this PR does by calling the `getLabwareDefsByURI()` selector. ## Test Plan and Hands on Testing Tested PD by hand locally. Ran all the CI tests. ## Risk assessment Low-ish. This PR doesn't change any functionality yet, it just hydrates the tiprack definition into `Hydrated*FormData`. An upcoming PR will change the low-level functions to use the hydrated tiprack definition in `Hydrated*FormData.tipRack`.
…Definitions() [cherrypick] (#20044) # Overview This is a cherry-pick of PR #19916. In that PR, I said that I would only apply that change to `edge`, and leave the PD branch alone because `chore_release-pd-8.6.1` was frozen and about to be released, and the files with the obsolete call were not used by the PD CI tests at all. Well, it turns out that a change I want to make to the PD branch now does trigger the `hardware-sim/` tests for some reason: https://github.com/Opentrons/opentrons/actions/runs/19088629372/job/54534570318 So now I need to cherrypick this change back into the PD branch. ## Test Plan and Hands on Testing CI really really hard. ## Risk assessment Low-ish. (cherry picked from commit 04e051d)
…Def instead of URI (#20039) # Overview The `getMaxConditioningVolume()` function previously took a tiprack URI and tried to look up the tiprack definition in `labwareEntities`. However, that could be unreliable if the tiprack URI refers to a tiprack that has been removed from the deck, because the tiprack would no longer be in `labwareEntities`. Now that the tiprack definition is available in the hydrated form, this PR changes `getMaxConditioningVolume()` to just take in the tiprack definition directly instead of trying to look it up in `labwareEntities`. ## Test Plan and Hands on Testing Smoke tested PD running locally. Ran `yarn vitest --silent=false step-generation/ protocol-designer/ app/`. Will run CI tests. ## Risk assessment Low-ish.
…irectly (#20047) # Overview `getMatchingTipLiquidSpecs()` takes a tiprack URI string, and tries to find the labware definition for the tiprack. This has been causing a ton of failures because the tiprack might not be in `PipetteEntity.tiprackLabwareDef` (if the tiprack has been disassociated from the pipette) nor in `InvariantContext.labwareEntities` (if the tiprack has been removed from the deck). A previous bandaid tried to fall back to looking up the tiprack in `getAllDefinitions()` (PR #19874), but that would still fail if tiprack is custom, because `getAllDefinitions()` only contains standard labware. In this final long-term fix, we change `getMatchingTipLiquidSpecs()` to take in the tiprack definition instead of the tiprack URI string. The caller is responsible for supplying the correct tiprack definition: - When the caller is using the `HydratedFormData`, such as in `mixFormToArgs.ts` and `moveLiquidFormToArgs.ts`, the caller can just get the tiprack definition from `HydratedFormData.tipRack`. We previously changed hydration to put the tiprack definition into `.tipRack` (PR #20034), and that works correctly for both custom and default tipracks. - When the caller is using the `rawForm`, such as in `StepFormToolbox.tsx` and other React components, the caller can `useSelector(getLabwareDefsByURI)` to get the tiprack definition. This selector returns both custom and default labware, so it also works correctly. Sorry this is kind of long. ## Test Plan and Hands on Testing Updated unit tests. Ran `yarn vitest --silent=false step-generation/ protocol-designer/ app/`. Smoke-tested PD running locally. Will run CI tests. ## Risk assessment Low-ish.
…tMatchingTipLiquidSpecsFromSpec() (#20048) # Overview The last one! Back in PR #19041, @ncdiehl introduced `getMatchingTipLiquidSpecsFromSpec()`, which was almost an exact a copy of `getMatchingTipLiquidSpecs()` except that it looked up the tiprack definition differently, because Nick's `getMatchingTipLiquidSpecsFromSpec()` did not have access to the `PipetteEntity.tiprackLabwareDef`. After the recent refactorings, the caller passes in the tiprack definition into both `getMatchingTipLiquidSpecs()` and `getMatchingTipLiquidSpecsFromSpec()`, so now there is no difference between the 2 functions anymore. So this PR merges the 2 functions together and eliminates `getMatchingTipLiquidSpecsFromSpec()`. ## Test Plan and Hands on Testing Run CI tests. ## Risk assessment Low.
# Overview Thought I had added these checks to everything but only added them to dynamic mix.
# Overview This PR enables mixpanel tracking for We will track - Camera enablement & settings - Photo usage - Live feed usage - Photo access and management ## Test Plan and Hands on Testing - View analytics of robots in office on mixpanel ## Changelog ## Review requests - Ensure I am not missing any spots in the code base where a camera action can be set. - How do I get livestream open duration time? ## Risk assessment low
Lots of conflicts: - components/src/hardware-sim/Pipette/PipetteRender.stories.tsx - protocol-designer/src/form-types.ts - protocol-designer/src/pages/Designer/ProtocolSteps/StepForm/StepTools/MoveLiquidTools/SecondStepsMoveLiquidTools.tsx - protocol-designer/src/pages/Designer/ProtocolSteps/StepForm/index.tsx - protocol-designer/src/steplist/fieldLevel/index.ts - protocol-designer/src/steplist/formLevel/handleFormChange/utils.ts - protocol-designer/src/steplist/formLevel/stepFormToArgs/mixFormToArgs.ts - protocol-designer/src/steplist/formLevel/stepFormToArgs/moveLiquidFormToArgs.ts - protocol-designer/src/steplist/formLevel/stepFormToArgs/test/mixFormToArgs.test.ts
…volume is out of bounds (#20056) # Overview Add a default value for the thermocycler max block volume when the found well volume is out of bounds ## Test Plan and Hands on Testing Simulated protocol `/Users/rhyannclarke/opentrons/abr-testing/abr_testing/protocols/active_protocols/4_Illumina DNA Enrichment.py` with apiLevel to 2.27 and received this error: `ProtocolCommandFailedError [line 299]: Error 4000 GENERAL_ERROR (ProtocolCommandFailedError): InvalidBlockVolumeError: Thermocycler max block volume must be between 0 and 100, but got 150.0.` After the change was made, the protocol simulated successfully with `start_set_block_temperature()` and `set_block_temperature()` ## Changelog - Added default block temperatures based on if it was higher than the max or lower than the min ## Risk assessment low Closes RQA-4820
# Fix Slack notifications to prevent workflow failures Fixes two issues with Slack notifications: 1. **Added missing `webhook-type` input** to `simple-build-alert` action (required by `slackapi/[email protected]`) 2. **Made all Slack notifications non-blocking** by adding `continue-on-error: true` to 5 notification steps in `app-test-build-deploy.yaml` Slack notification failures will no longer cause workflow failures, while still logging warnings for debugging.
…20077) Ensures the configuration file that use to default to "NONE" now reinforces the new oe-core default.
# Overview This PR updates the OT3 Controller's motion planning to adjust the commanded speed for a multi axis move if one of the plunger's are in the moving axis. this ensures that the pipettes' plunger will move at the speed commanded. Right now we only move the plunger and other axis during dynamic pipetting so this won't affect anything else in the system. After doing it's best to adjust this speed, if the move is still impossible an error will be logged into the api logs.
… color on camera settings (#20061) # Overview Removed wrapping behavior of module icons in protocol card and robot card Corrected text on camera settings in run setup Updated camera enabled text to a chip ## Test Plan and Hands on Testing Smoke tested: <img width="931" height="332" alt="Screenshot 2025-11-06 at 12 35 10 PM" src="https://github.com/user-attachments/assets/696b8acd-a14f-4b32-95c6-7643240d3ee5" /> <img width="931" height="149" alt="Screenshot 2025-11-06 at 4 11 08 PM" src="https://github.com/user-attachments/assets/b37ebf6b-7a86-4b6b-95f8-98950bbbe47e" /> <img width="900" height="547" alt="Screenshot 2025-11-06 at 3 15 43 PM" src="https://github.com/user-attachments/assets/d8198898-5852-4930-9830-85385138b68c" /> <img width="913" height="564" alt="Screenshot 2025-11-06 at 3 21 59 PM" src="https://github.com/user-attachments/assets/7a5e8bcd-6cab-417a-9724-ac342613d165" /> <img width="991" height="617" alt="Screenshot 2025-11-06 at 4 19 05 PM" src="https://github.com/user-attachments/assets/d4c4266a-45b0-4c3d-874b-5078a79c564c" /> ## Risk assessment low Closes RQA-4819 Closes RQA-4825 Closes RQA-4824 Closes RQA-4830 Closes RQA-4823 Closes RQA-4835
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.
8.8.0