chore(release): 7.3.0 #15069
Merged
chore(release): 7.3.0 #15069
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
* refactor(components): update parameter table stories
* refactor(components): update Box stories
# Overview Add feature flag for Performance Metrics project. Closes https://opentrons.atlassian.net/browse/EXEC-372 # Changelog - Add enablePerformanceMetrics feature flag in advanced settings - Add migration function - Update tests
* refactor(app): remove RTP feature flag
Closes AUTH-255 # Overview Adds a POST method to the existing `/protocols/{protocolId}/analyses` endpoint in order to post a new analysis for an existing protocol. This endpoint will take a request body with two optional fields: - `runTimeParameterValues` - `forceReAnalyze` The new method can affect the analyses in three ways: 1. When the request is sent with `forceReAnalyze=True`, the server will unconditionally start a new analysis for the protocol using any RTP data sent along with it. It will return a 201 CREATED status and respond with a list of analysis summaries of all the analyses (ordered oldest first), including the newly started analysis. 2. When the request is sent without the `forceReAnalyze` field (or with `forceReAnalyze=False`), then the server will check the last analysis of the protocol - if the RTP values used for it were **different** from the RTP values sent with the current request, then the server will start a new analysis using the new RTP values. It will return a 201 CREATED status and respond with a list of analysis summaries of all the analyses, including the newly started analysis. - if the RTP values used for it were the **same** as the RTP values sent with the current request, then the server will **NOT** start a new analysis. It will return a 200 OK status, and simply return the existing list of analysis summaries. This request requires the last analysis of the protocol to have been completed before handling this request. If the last analysis is pending, it will return a 503 error. # Test Plan Test out the above three cases and anything else you can think might affect the behavior. It's pretty well tested in unit & integration tests and it is also the same logic used for handling analyses from `POST /protocols`, so it is expected to work well when used as tested in integration tests. # Review requests Usual review for code sanity check. # Risk assessment Low. New HTTP API not yet used anywhere.
<!-- Thanks for taking the time to open a pull request! 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 To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview This PR adds a new testing script that allows us to test all kinds of variations of the liquid-sense routine it adds some additional features in the hardware control layer to change up output options to during the probe so we can gate using the buffer-on-pipette feature to a firmware version flag, since that feature has to be compiled in separately <!-- Use this section to describe your pull-request at a high level. If the PR addresses any open issues, please tag the issues here. --> # Test Plan <!-- Use this section to describe the steps that you took to test your Pull Request. If you did not perform any testing provide justification why. OT-3 Developers: You should default to testing on actual physical hardware. Once again, if you did not perform testing against hardware, justify why. Note: It can be helpful to write a test plan before doing development Example Test Plan (HTTP API Change) - Verified that new optional argument `dance-party` causes the robot to flash its lights, move the pipettes, then home. - Verified that when you omit the `dance-party` option the robot homes normally - Added protocol that uses `dance-party` argument to G-Code Testing Suite - Ran protocol that did not use `dance-party` argument and everything was successful - Added unit tests to validate that changes to pydantic model are correct --> # Changelog <!-- List out the changes to the code in this PR. Please try your best to categorize your changes and describe what has changed and why. Example changelog: - Fixed app crash when trying to calibrate an illegal pipette - Added state to API to track pipette usage - Updated API docs to mention only two pipettes are supported IMPORTANT: MAKE SURE ANY BREAKING CHANGES ARE PROPERLY COMMUNICATED --> # Review requests <!-- Describe any requests for your reviewers here. --> # Risk assessment <!-- Carefully go over your pull request and look at the other parts of the codebase it may affect. 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 in protocol may also change the behavior of labware calibration. Identify the other parts of the system your codebase may affect, so that in addition to your own review and testing, other people who may not have the system internalized as much as you can focus their attention and testing there. --> --------- Co-authored-by: caila-marashaj <[email protected]>
<!-- Thanks for taking the time to open a pull request! 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 To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview <!-- Use this section to describe your pull-request at a high level. If the PR addresses any open issues, please tag the issues here. --> Improved ABR Error Data Collection # Test Plan Tested code on multiple robots. # Changelog Added function to download robot logs Added lines of code to move error documents (run log, calibration log, robot logs) into folder named after ticket. Adds robot run to ABR sheet and links JIRA ticket Added extra lines to abr_scale to read scale more often Edited ABR calibration script to ensure duplicate calibrations are not added. # Review requests Is 5000 lines of recording enough to capture robot error if script is run immediately? Is there any manipulation to robot logs that can be down to make error analysis more efficient. # Risk assessment <!-- Carefully go over your pull request and look at the other parts of the codebase it may affect. 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 in protocol may also change the behavior of labware calibration. Identify the other parts of the system your codebase may affect, so that in addition to your own review and testing, other people who may not have the system internalized as much as you can focus their attention and testing there. -->
Into edge instead of release branch. Was #14840 Co-authored-by: Jamey Huffnagle <[email protected]>
* fix(shared-data, app): fix runtime parameters range display
When we switched to vite, we had to switch all the stuff we'd been injecting at pack time via webpack environment/define plugins to vite's `define` config functionality. The biggest thing we specify that way is the app version, which is used across the stack for display and for logic. In the commit that switched to vite, we added that injection for the app-shell vite configs but did not add it for the app vite configs. That meant that at runtime, the version value was undefined, which breaks robot update notifications and causes the app version in the general settings tab to not display (it also makes the logo wrong on internal releases but that's a bit less important). The fix is to inject the version into the app build again. This is made a little more complicated because if you're doing stuff to the app vite config, it has to work in both the vite devserver and the vite offline packaging environments, and the vite devserver doesn't allow commonjs, and the git-version script that gives us the version is commonjs. For the purposes of vite's devserver, "doesn't work with cjs" actually just means "doesn't support require()", so you can use a hybrid syntax that uses import-statements but still module.export instead of export statements. Unfortunately, the git-version script is also used in the electron-builder config for the app-shell and the app-shell-odd, and the electron-builder config is run via node, and to import an ESM from a node CJS script - which electron-builder.config.js is - you need to change your import syntax to dynamic import and you need to make the import target explicitly (to node) an ESM, aka change its extension, and you need to use full ESM syntax including exports. This also goes for the create-release script. So that means that - git-version.js becomes git-version.mjs and uses full ESM syntax - that means that everywhere it's imported we need to import it by full path with extension instead of module name - also we need to import it dynamically in the electron config - oh and we need to actually add the define configs so we get the version in the app And then finally we show the version again. Also, remove some old webpack.config.js files that aren't used anymore. Closes EXEC-385
* fix(shared-data, app): fix small issues in app
* fix(discovery-client): fix import statement
…rons-ai (#14788) * feat(opentrons-ai-client, opentrons-ai-server): add folders for opentrons-ai
This PR is an automated snapshot update request. Please review the changes and merge if they are acceptable or find you bug and fix it. Co-authored-by: y3rsh <[email protected]>
* fix(app): fix rtp slideout issue
* fix(app-shell-odd): fix typo in vite-config
The schema changes in edge weren't in release and need to be manually merged. Closes RQA-2558
) Closes AUTH-379 # Overview #14345 updated the module ports filtering to exclude any temporary ports created by udev. But the regex used for port name matching filters out only Flex port names (e.g. `ot_module_thermocycler2.tmp-c166:2`). This PR adds regex to filter out OT-2 temp ports as well (e.g. `.#ot_module_thermocycler0b494617b5e4f08ae`). # Risk assessment Medium. Can affect module connectivity but is easy to test and rule out any issues.
* fix(app): update InputField styling
* fix(app): remove padding from lpc flex box
…on liquid map (#15132) Closes RQA-2699 At protocol setup on desktop, when viewing liquid setup > map view, liquids are incorrectly set to null for labware nested on an adapter, which is in turn nested on a module. We need to pass the topmost nested labware to getWellFillFromLabwareId to correctly return populated well fill.
* fix(app): fix font size in lpc table
Fix Deck hardware table padding in desktop protocol setup. Fix padding in no modules detected modal. standardize copy for title and description fo protocol setup steps. standardize copy for header and description in ODD location conflict modal Closes [RQA-2687](https://opentrons.atlassian.net/browse/RQA-2687), Closes [RQA-2686](https://opentrons.atlassian.net/browse/RQA-2686), Closes [RQA-2684](https://opentrons.atlassian.net/browse/RQA-2684), Closes [RQA-2685](https://opentrons.atlassian.net/browse/RQA-2685), Closes [RQA-2692](https://opentrons.atlassian.net/browse/RQA-2692)
…component (#15145) * fix(app): fix password button rendering issue and update input field component
RQA-2700 Ensure automatic tip tracking for partial configurations does not exceed the limits of the tiprack it is iterating over
<!-- Thanks for taking the time to open a pull request! 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 To ensure your code is reviewed quickly and thoroughly, please fill out the sections below to the best of your ability! --> # Overview After conducting hardware testing, we've formulated updated tip overlap values for every tip size and pipette model. These adjustments apply to 1-channel, 8-channel, and 96-channel pipettes. These revised values aim to mitigate overpressure occurrences in ABR. [https://docs.google.com/spreadsheets/d/16dEmqulO4SIKU6E0aYTfVQEnZRTn3MwNF_WB8K1KmRM/edit#gid=0](url) <!-- Use this section to describe your pull-request at a high level. If the PR addresses any open issues, please tag the issues here. --> # Test Plan None <!-- Use this section to describe the steps that you took to test your Pull Request. If you did not perform any testing provide justification why. OT-3 Developers: You should default to testing on actual physical hardware. Once again, if you did not perform testing against hardware, justify why. Note: It can be helpful to write a test plan before doing development Example Test Plan (HTTP API Change) - Verified that new optional argument `dance-party` causes the robot to flash its lights, move the pipettes, then home. - Verified that when you omit the `dance-party` option the robot homes normally - Added protocol that uses `dance-party` argument to G-Code Testing Suite - Ran protocol that did not use `dance-party` argument and everything was successful - Added unit tests to validate that changes to pydantic model are correct --> # Changelog ### **Pipette shared data** ### P1KS Single Channel - Updated V3_5 Tip Overlap values for 50uL, 200uL, and 1000uL tips. - Updated V3_6 Tip Overlap values for 50uL 200uL, and 1000uL tips. ### P50S Single Channel Pipette - Updated V3_5 Tip Overlap values for 50uL, 200uL, and 1000uL tips. - Updated V3_6 Tip Overlap values for 50uL 200uL, and 1000uL tips. ### P1KM 8 Channel Pipette - Updated V3_5 Tip Overlap values for 50uL, 200uL, and 1000uL tips. - Updated V3_6 Tip Overlap values for 50uL 200uL, and 1000uL tips. ### P50M 8 Channel Pipette - Updated V3_5 Tip Overlap values for 50uL, 200uL, and 1000uL tips. - Updated V3_6 Tip Overlap values for 50uL 200uL, and 1000uL tips ### P1H 95-Channel Pipette - Updated V3_5 Tip Overlap values for 50uL, 200uL, and 1000uL tips. - Updated V3_6 Tip Overlap values for 50uL 200uL, and 1000uL tips <!-- List out the changes to the code in this PR. Please try your best to categorize your changes and describe what has changed and why. Example changelog: - Fixed app crash when trying to calibrate an illegal pipette - Added state to API to track pipette usage - Updated API docs to mention only two pipettes are supported IMPORTANT: MAKE SURE ANY BREAKING CHANGES ARE PROPERLY COMMUNICATED --> # Review requests <!-- Describe any requests for your reviewers here. --> # Risk assessment Low <!-- Carefully go over your pull request and look at the other parts of the codebase it may affect. 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 in protocol may also change the behavior of labware calibration. Identify the other parts of the system your codebase may affect, so that in addition to your own review and testing, other people who may not have the system internalized as much as you can focus their attention and testing there. --> --------- Co-authored-by: Seth Foster <[email protected]>
# Overview Communicating https://opentrons.atlassian.net/browse/RQA-2554 as a known issue that will be present in 7.3.0 # Review requests Accurate and sufficient? # Risk assessment none
…eAllCommandsAsPreSerializedList (#15188) React query does not properly handle objects passed in useQuery's queryKey array argument that contain keys with `undefined` values. Here, in `useAllCommandsAsPreSerializedList`, I map undefined values to null so that they are properly cached and do not trigger a refetch when the host object does not change.
…ype via RTP (#15194) # Overview Letting people know they can get chicken-and-egg'd if they apply labware offsets, set RTPs that change their labware, and then reanalysis gets rid of their original offsets. # Review requests Is this clear? This is kind of a tricky one to wrap up in a single sentence. # Risk assessment zip
…w OT2 module setup (#15204) Don't look to deck configuration for matching specced modules to attached modules within the module setup step of the OT-2 Closes [RQA-2735](https://opentrons.atlassian.net/browse/RQA-2735)
Closes RQA-2730 Remove InterventionModal if run is finishing
…15202) Instead of the previous method of staging a batch of changes to deck configuration before commiting them with the confirm button, to avoid synchronization issues, make the ODD deck configurator behave like the desktop version. all updates immediately permeate to the robot's source of truth Re: https://opentrons.atlassian.net/browse/RQA-2669
I think this would be a subtle side effect of a previous pr trying to improve PE end behavior. The reason this fix is required is that when a client cancels a protocol by stopping the engine, the `StopAction` sets the run result (good) and doesn't set a run error (good, correct, there wasn't one, this is a cancel). In 7.2, with the behavior this PR now restores, a `FinishAction` that might contain an error wouldn't set that error in the run if it already had a _result_, whether or not it had an _error_. In 7.3, it would set the error if the engine had no error, which it wouldn't, because there is no error when you stop. ## Testing - [x] With this PR, cancelling a run on a real robot causes the ODD to show an inactive error details button - [x] With this PR, stopping a run by hitting an estop still causes the ODD and desktop to display that an estop error cancelled the run Closes RQA-2737 --------- Co-authored-by: Max Marrone <[email protected]>
…nt for thermocycler occupying 2 slots (#15239) Ensure slot conflict checking accounts for the thermocycler being comprised of two fixtures in the deck config when validating the cutout fixtures.
…f the required modules (#15232) Fix bug where we were accidentally filtering magnetic modules instead of magnetic blocks from the required modules list from analysis. Closes [RQA-2754](https://opentrons.atlassian.net/browse/RQA-2754)
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 release tracking branch for 7.3.0