chore(merge): 8.0.0 alpha.0 mergeback #15940
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
re AUTH-591 <!-- 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. --> Send and save the CSV RTPs used in protocol runs to the new table created in the database, and hook it up to the GET endpoint that fetches all the data files used in analysis and run. ## 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. --> - run test files to ensure that csv rtps get insert to the new run_csv_rtp_table and able to get them from the table ## Changelog <!-- List changes introduced by this PR considering future developers and the end user. Give careful thought and clear documentation to breaking changes. --> - Added `run_csv_rtp_table` to schema_6.py file - Added runTimeParameterFiles field to the run creation request model - Passed rtp files input onto the Run Orchestrator’s load process - Added `insert_csv_rtp()` and `get_all_csv_rtp()` function - Updated `get_reference_data_files()` to add file referenced in runs - Updated tests --------- Co-authored-by: shiyaochen <[email protected]> Co-authored-by: Sanniti <[email protected]>
… and runs to set in-protocol values (#15855) # Overview Closes AUTH-419. This PR hooks up the setting of runtime parameter files in the POST `/runs`, `/protocols` and `/protocols/{protocolId}/analyses` to the actual `CSVParameter` object used in the protocol context. This file is sent via a dictionary of parameter name and file-id, so we resolve the file-id into a `Path` by using the `data_files_directory` and `data_files_store`. This is then passed to the `ParameterContext` and used to open up a temporary file that contains the contents of the actual file stored on the robot. ## Test Plan and Hands on Testing Tested end to end via the following protocol and two CSV files ``` metadata = { 'protocolName': 'CSV End to End Test', } requirements = { "robotType": "Flex", "apiLevel": "2.18" } def add_parameters(parameters): parameters.add_str( display_name="Pipette Name", variable_name="pipette", choices=[ {"display_name": "Single channel 50µL", "value": "flex_1channel_50"}, {"display_name": "Single channel 1000µL", "value": "flex_1channel_1000"}, {"display_name": "Eight Channel 50µL", "value": "flex_8channel_50"}, {"display_name": "Eight Channel 1000µL", "value": "flex_8channel_1000"}, ], default="flex_1channel_50", description="What pipette to use during the protocol.", ) parameters.add_csv_file( display_name="CSV Data", variable_name="csv_data", description="CSV file containing labware and volume information." ) def run(context): PIPETTE_NAME = context.params.pipette trash_bin = context.load_trash_bin('A3') tip_rack = context.load_labware('opentrons_flex_96_tiprack_50ul', 'D2') pipette = context.load_instrument(PIPETTE_NAME, mount="left", tip_racks=[tip_rack]) csv_file_data = context.params.csv_data.parse_as_csv() labware_name = csv_file_data[1][0].strip() location = csv_file_data[1][1].strip() volume = float(csv_file_data[1][2]) labware = context.load_labware(labware_name, location) pipette.pick_up_tip() pipette.aspirate(volume, labware.wells()[0].top()) pipette.dispense(volume, labware.wells()[1].top()) pipette.drop_tip() ``` ``` Labware Name, Location, Volume opentrons_96_wellplate_200ul_pcr_full_skirt, C1, 20 ``` ``` Labware Name, Location, Volume nest_96_wellplate_100ul_pcr_full_skirt, C2, 30 ``` ## Changelog - Resolve `runTimeParameterFiles` into a dictionary of `Paths` - pass the `run_time_param_paths` all the way to the `ParameterContext` where they can be opened as temporary file handlers - close the file handlers upon protocol end - Allow importing of `CSVParameter` from the `protocol_api` namespace. ## Review requests ## Risk assessment Medium. --------- Co-authored-by: Sanniti <[email protected]>
* fix(app)switch navlink to useNavigate for tabas in run setup
# Overview According to new modal designs for labware/adapter/module stacks on desktop and ODD, we need to render an isometric view of each element of the stack, maintaining the topography of each stacked element. The isometric views are constructed by transforming and aligning the labware SVG (top face) along with two new rects (front and left side). All three are scaled, skewed, and rotated at 30˚ angles or its derivatives ([reference](http://jeroenhoek.nl/articles/svg-and-isometric-projection.html)). The "bottom" labware definition is an optional prop, so we have an affordance for rendering an isometric view of a single labware from the same component. The user can choose to highlight both or none of the labware in the stack, resulting in a fill of blue30. In addition, adapters are handled in the following way: - If the adapter is used as the top definition and there is no bottom definition, we render the non-transformed `LabwareAdapter` svg - if the adapter is used as the bottom definition, we render the isometric transform of the well-less adapter face. _**NOTE**_ In this PR, the adapter's height is maintained, but we may also consider setting the height for a bottom adapter as a constant, rendering a standard-height rectangular prism with well-less face. Closes [PLAT-374](https://opentrons.atlassian.net/browse/PLAT-374), [PLAT-377](https://opentrons.atlassian.net/browse/PLAT-377), [PLAT-394](https://opentrons.atlassian.net/browse/PLAT-394), [PLAT-375](https://opentrons.atlassian.net/browse/PLAT-375)
…5883) # Overview closes https://opentrons.atlassian.net/browse/EXEC-504. add an end point in runs router to fetch commands error list. ## Test Plan and Hands on Testing - Post a protocol that will cause a recovery workflow. - Start the run and let the command fail. - Resume from recovery. - Let the run end. - GET `/runs/{runId}/commandErrors` and make sure you are getting the full command error list. ## Changelog - added an end point to commands router `/runs/{runId}/commandErrors`. - added logic in `CommandsState` to `get_error_slice`. ## Review requests naming makes sense? changes make sense? location for the new route makes sense? (under commands router) ## Risk assessment low. adding new logic
Closes RQA-2842 Migrates the logic for building RunProgressMeter's step copy to its own utility, cleaning up the order of operations slightly. Refactors the final step text from nothing to "N/A" when the run is canceled before starting.
…ise `MustHomeError` (#15900)
Co-authored-by: Ed Cormany <[email protected]>
In the run page on both app and ODD, you get an indication of completion when you get all your instruments and modules and deck stuff present and calibrated. But those are just two of the steps presented equally in the run setup page, and the rest of the steps don't get anything similar. It leads people to wonder whether they've set things up properly. This PR adds similar styling and completion semantics for the other tasks in the run setup screen to fix this issue. Specifically, LPC gets a "confirm offsets" button (which will confirm offsets even if you haven't run LPC - makes it more apparent that that's a separate option) and labware and liquids get generic confirm buttons. There's also a couple other visual fixes: - On desktop, the "back to top" button in run setup is now where figma thinks it is, outside the run-setup content area. This allows some refactoring of component props - On desktop, there was an issue with the react-router upgrade (I think - it's also in the latest IR alpha) that means that if you had an ongoing run, you couldn't view anything but run details without getting instantly navigated back to run details This implements this figma: https://www.figma.com/design/Rwdt9R0aERFC55oTLDTlqY/8.0-September-Release-File?node-id=39-35830&t=l6vwJjQsfyVeovfC-4 ## To come out of draft - [x] implement for ODD - [x] rebase onto release - [x] "are you sure" modal on desktop - [x] "are you sure" modal on ODD ## Review requests - This is some pretty complex UI - do you agree with how I've done this? - Some of this is pretty ugly, in large part because this is old code that I'm cleaning up. There's some duplicated logic in the run details and some pretty ugly typing. What I'd like to do is merge this since it implements some features nicely and then follow up with a refactor to get the size of some of these files down and enforce nicer separation between everything. ## Testing - [x] Desktop green checks on flex - [x] Desktop green checks on OT-2 (yes, this has to be different because the steps can be different here) Closes RSQ-7
…tocolContext.define_liquid()` (#15906)
…5913) <!-- 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 Should have realized it was wrong when I had to change the test <!-- 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]>
Closes RQA-2904 The logic for rendering InterventionModal on the ODD/Desktop is a little bit different when looking at the exact conditions, and this (likely) causes the InterventionModal to render on the ODD sometimes but not on the desktop app, and vice versa. This is a good opportunity to refactor all of this logic into its own hook and use that hook where we render InterventionModal. After thinking through the render logic, there's room to simplify it a bit, too. We don't actually need stateful storage of an intervention command key. Also, I decided to separate showModal from modalProps (which lets us pass all the non-null props simply), even though we could technically just do a truthy check for modalProps for rendering InterventionModal, since this is maybe a bit more intuitive. Lastly, a few missing tests are added. To help with bug testing intervention modals, I added a couple console.warns.
To give clarity to the contents of labware/adapter/module stacks, here, I add a modal when clicking a stack on Labware setup deck map (for both Desktop and ODD). Each element of the stack will be highlighted described in a list item containing the element's name, optional nickname, and isometric SVG or PNG representation depending on its type. Closes [PLAT-376](https://opentrons.atlassian.net/browse/PLAT-376), [PLAT-378](https://opentrons.atlassian.net/browse/PLAT-378)
Fixes accidental reversion resulting in populating file name on `FileCard` with empty string. We need to reach into `csvParam.file.file.name` rather than just `csvParam.file.name` on desktop.
# Overview Update `LegacyModalHeader` according to new designs to accept up to 2 elements ahead of title text. Add props to `LegacyModal` that are passed down to header, and implement at `LabwareStackRender` <img width="532" alt="Screenshot 2024-08-07 at 11 57 09 AM" src="https://github.com/user-attachments/assets/537f5a7c-b148-4641-b000-40da0d8da3ea"> Closes PLAT-395
Adds optional `highRes` argument to `getModuleImage` util to retrieve higher res module images where applicable for use in `LabwareStackModal`.
…15908) Closes AUTH-638 # Overview Fixes a bug where CSV files used in protocol runs were not being saved to the CSV RTP table for runs, and as a result, were not being included in response for the `/protocols/{protocolId}/dataFiles` endpoint. ## Test Plan and Hands on Testing Testing with app & ODD: - [x] Upload a protocol that uses a CSV parameter - [x] Send the protocol to a robot, upload the csv file to use - [x] Run the protocol - [x] Run the protocol again with a different CSV file -> Do this 5 times (so total 6 runs with 6 different CSV files). By re-running the protocol 6 times, we are making the robot delete its oldest analysis (since max analyses per protocol is 5), essentially deleting the first CSV file from the *analysis* csv table, but not from runs table - [x] Check that when you run the protocol again on the ODD, it shows you all the 6 different CSV files previously uploaded Testing with Postman/ direct HTTP requests: - [x] Upload a few data files - [x] Upload a protocol that uses a CSV parameter and specify a data file (data_file_1) for the CSV param - [x] Start a new analysis for the same protocol by specifying a second data file (data_file_2) for the CSV param - [x] Create a run for the protocol by specifying data_file_1 for its CSV param - [x] Create another run for the protocol by specifying a third data file (data_file_3) for its CSV param - [x] Check that the response to `GET /protocols/{protocolId}/dataFiles` contains the 3 data files used with the runs & analyses. Check that they are listed in the order that the files were uploaded to the server (via `POST /dataFiles`) ## Changelog - wired up CSV RTP table insertion during run creation - updated the run deletion code to remove the CSV RTP entry from the `run_csv_rtp_table` before deleting the run. - updated the `../{protocolId}/dataFiles` response so that it lists the files in the order they were uploaded. - added tests ## Risk assessment Low. Fixes bug
# Overview This PR addresses some refactor suggestions made in previous PRs ## Changelog - check if data file directory exists before deleting it - refactored `FileInUseError`'s message formatting - small code improvement in `completed_analysis_store` ## Risk assessment None.
Pass `LegacyModal` title text and icon elements as separate props in `LabwareStackModal`
# Overview This PR follows up on #15855 with various small refactors/improvements. The biggest change in this PR is refactoring how we open the CSV parameter files. Previously we were opening them when we first initialized the parameter. This proved to be a potential issue because we were only closing the files when we reached the execute step of running the protocol (i.e. in a `finally` clause within `run_protocol`), yet there was the small yet possible chance of not reaching that step (for instance if the initial home command failed unexpectedly). To solve this, we are now passing the `Path` object to the `CSVParameter` interface and only opening the file when it is first accessed in the protocol, meaning it will _always_ occur within that try/except block. Another change introduced is properly raising a 400 error for `POST`s to the `/runs`, `/protocols` and `/protocols/{protocolId}/analyses` endpoints when referencing data files (for runtime parameter files) that don't exist. API Version is now also enforced for using `add_csv_file` which now requires your protocol to be at 2.20. The api version is also now passed down to the `CSVParameter` interface, though it is not currently used to gate anything yet. ## Test Plan and Hands on Testing Tested end to end on hardware with the same protocol/csv files as #15855. ## Changelog - Pass `Path` to `CSVParameter` interface and open files within that. - Raise a 400 error when referencing non existent data file IDs for `/runs`, `/protocols` and `/protocols/{protocolId}/analyses` - Require API version 2.20 for `add_csv_file` - Fixes/improvements for testing CSV files/file opening in protocol api ## Review requests ## Risk assessment Low.
<!-- 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. --> --------- Co-authored-by: caila-marashaj <[email protected]>
# Overview closes https://opentrons.atlassian.net/browse/EXEC-635 (minos a few bug fixes ;-) ) show full error list in the run summery modal. ## Test Plan and Hands on Testing - run the desktop app/odd. - enter ER mode and make sure you encountered command errors. - finish the run and click the view error details -> make sure you can see the error encountered. ## Changelog - added get calls for the run command error list - updated FailedRunModal to show the full error list if we got it. ## Risk assessment low. should not affect existing code.
adds helix caption bold to storybook re PLAT-408
# Overview Release notes for 8.0.0. ## Test Plan and Hands on Testing Check display when alpha0 is cut. ## Changelog The usual two files. ## Review requests Any features, bugs, or known issues that need to be added? ## Risk assessment nil
…`getCsvFile` (#15926) Add new api-client function for `getCsvFile`, which takes a fileId and returns `CsvFileData`: ``` { id: string createdAt: string name: string } ``` Wrap in react query hook and implement in `HistoricalProtocolRunDrawer`.
Render proper modal depending on if labware is top element of stack or loaded directly on deck. Refactors to use the same state variable to keep track of the selected labware, and determines which modal to show depending on if the selected labware was loaded onto a module/adapter or directly onto the deck.
Guess we never got around to updating these. They're correct for [the release file](https://www.figma.com/design/Rwdt9R0aERFC55oTLDTlqY/8.0-September-Release-File?node-id=218-35940&t=wOA3qgaCJdi9T3ub-4) Closes RQA-2919
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## edge #15940 +/- ##
==========================================
+ Coverage 60.19% 63.31% +3.11%
==========================================
Files 190 300 +110
Lines 10650 15773 +5123
==========================================
+ Hits 6411 9986 +3575
- Misses 4239 5787 +1548
Flags with carried forward coverage won't be shown. Click here to find out more.
|
sanni-t
approved these changes
Aug 8, 2024
caila-marashaj
force-pushed
the
8.0.0-alpha.0-mergeback
branch
from
61d23fc to
cd54d90
Compare
This was referenced Aug 13, 2024
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 a mergeback of 8.0.0 as of alpha.0 (and a couple extras) to edge. It's important to do these more often this cycle because we landed some big FE refactors right after branching.
Note on process: