Chore release ot3@1.5.0 stable missed merge #15305
Merged
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
* feat(app): add small size to Chip component for ODD
Closes EXEC-350 There is no current logic when presenting lists of robots on the Devices tab, sending protocols slideouts, etc. Sort robots alphabetically.
Closes EXEC-319 This is the app-shell-odd equivalent of the app-shell refactor, #14648. It's similar to the app-shell logic, but significantly simpler, since we don't have to manage multiple robots, worry about localhost port blocking, and multiple IPs per robot. The real change lies in the initial connect and final disconnect on app shutdown. Otherwise, the changes are primarily in the ConnectionStore. Because the app no longer utilizes unsubscribe actions in any capacity, we can safely remove those references.
* refactor(app): create utils to format value for rtp
…4715) * refactor(components, app): move StyledText from app to components
This PR enables the reporting of Flex motor driver errors, adding the MotorDriverError exception. Specific motor driver errors are over-temperature, short circuit, and open circuit. An ErrorMessage is reported from the Flex firmware in two cases: 1. As a response to a move request when a motor driver is in error state. In this case, the error is logged. 2. If a motor driver enters error state during a move. In this case, a subsequent ReadMotorDriverErrorStatusResponse message is reported from the Flex firmware, which details the specific error. This PR logs these messages and also raises these messages as MotorDriverError exceptions. <!-- 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. --> # Test Plan - [ ] Test both use cases on robot. In second use case, ensure ReadMotorDriverErrorStatusResponse message is associated with requesting MoveID. - [x] Write software tests for both use cases. In second use case, ensure each specific error is parsed. <!-- 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 Low. Adds MotorDriverError to existing list of exceptions. Introduces handling and parsing of ReadMotorDriverErrorStatusResponse message, using existing well-tested frameworks and concepts. <!-- 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. -->
…#14723) # Overview Follow-ups for #14711 (comment). #14711 added safer error propagation for when robot-server encounters bad stored run data. As part of that, if it finds a run where the `state_summary` SQL column is `NULL`, it treats that as bad data and propagates the error to HTTP clients. When you restart the robot while there is an active run, then no state summary will be inserted (this only happens when the run is ended and the state moves from engine to sql) and the run will be bad. We say that this is in fact a bad run because to the client, there is no distinction between state summary and run. A run with an empty state summary does not have correct data and does not represent what occurred. Add a regression test to make sure this is how we handle runs that did not have state summaries persisted. # Testing - [x] create a run with this branch on a flex and restart the flex (or kill the robot server process - this isn't about the details of when things are written to disk, just the lifetime of the data here) and see that the run is now bad --------- Co-authored-by: Seth Foster <seth@opentrons.com>
fix(app): fix chip storybook
When runs are bad, which means they couldn't be loaded correctly, we now get standin records called BadRuns rather than 500 errors. We should display that a run is bad on the ODD. For now, let's try making it red and displaying a status text. This is what this looks like. Thoughts? 
adds an enableOEMMode robot setting to track whether OEM mode is enabled for the ODD closes PLAT-186
* fix(app): update chip component style and Storybook
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 <y3rsh@users.noreply.github.com>
…14721) ncreased backlash compensation improves low-volume performance. NOTE: accuracy functions are copied over from v3.5 definition, will add new v3.6 functions in a follow-up PR estimated to be ready around April 3-8 when the data is ready
# Overview 7.2.2 hotfix release notes. # Changelog - Describes #14721 - No others so far # Review requests Anything else of note going into this release? # Risk assessment nil
…s in analysis (#14735) Runtime parameter values sent via protocols endpoint will now be set, and all parameters and values used are now reported in analysis.
…14738) <!-- 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 Connects ABR with Google Drive. # 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 Added modules for google_sheet writing and google_drive uploading Changed ABR data uploading to check google_sheet for run ids rather than the local csv Moved ABR files out of hardware testing # Review requests <!-- Describe any requests for your reviewers here. --> # Risk assessment ignoring typing errors in google_drive_tool due to issues with google-api-client-typing ignoring import errors with hardware_testing due to conflicting dependencies with google-api-client-typing
* feat(opentrons-ai-client): add prompt button
# ot3@1.5.0-alpha.0 release notes
…ed (#14990) # Overview Fixes https://opentrons.atlassian.net/browse/RQA-2623 performance directory was missing an `__init__.py` # Test Plan - I added a test just to import the module and create one of the objects inside the dev_types.py. The issue is that the tests don't run against the built version of the package. I built the app and everything imports correctly - I cannot test that opentrons_shared_data is being utilized correctly on the robot until I have a built buildroot image. Because currently my robot and app have different versions (due to the dev build) so the app will not let me trigger an analysis. - I instead pushed opentrons-shared-data to my robot and verified that the performance module existed in `/usr/lib/python3.10/site-packages/opentrons_shared_data`. But I can't test that the imports actually work until I have the system image and the app together # Changelog - Added `__init__.py` to performance directory to tell python to import it as a module - Reorganized performance_helpers.py to not have an import error # Review requests - Nothing to block this fix, but what should be done to make sure this doesn't happen again? This is a weird packaging thing that doesn't show up when running dev or CI testing. - I wonder if there is a smoke test we can perform automatically just to make sure everything imports correctly? Running opentrons.simulate against the actual built package would have caught this # Risk assessment Medium, I mean I can't break it any worse than I already did
## ot3@1.5.0-alpha.1 release notes
…ning bug. (#14993) This is a temporary workaround due to an invalid InRelease file published to the Microsoft Debian repository used by Ubuntu 22.04 (see microsoft/linux-package-repositories#130). The build jobs fail because apt-get update fails. TODO: Revert this when the issue is fixed
* feat(opentrons-ai-client): add style to container of Textarea
* fix(shared-data): remove sort from choices
When these are undefined, if react-markdown tries to render them it will throw and that will crash the app. With these implemented with the same StyledText passthrough as other text elements, it won't crash anymore - though our styling rules aren't applied to the actual text in the ul. Closes RQA-2566 Closes RQA-2587
<!-- 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 Pipette definitions for P50S v3.6, which accounts for a small hardware modification which affects the accuracy function. NOTE: function in the PR is still copied over from the v3.5 model. Updated v3.6 function will be added in a followup PR after testing is complete. <!-- 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: pmoegenburg <pbm53@cornell.edu>
…4836) * refactor(app): add RTP properties to protocol run event analytics
Adds a new command ReloadLabware, which allows dispatchers to change all the details of a loaded labware except for the location. This is primarily intended to allow getting a new labware offset that was not added to the engine by the time this labware was loaded (though it can technically do more, for symmetry). This doesn't really change a whole lot of behavior and is well-supported with testing. It's a prerequisite for #14940 Closes RSQ-29
## This is a copy of #15020
## Keep experimenting with the formatting of the release notes - `<br>` was no good - trying headers
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.
Due to my big hurry to get the stable internal release out, I neglected to remember we track
internal-releasebranch stable releases just likerelease.In this case we will