-
Notifications
You must be signed in to change notification settings - Fork 187
Merge back 'chore_release-pd-8.7.0' into 'edge' #20331
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
In addition to checking external collisions in `pickUpTip` command creator, we need to check that the tip pickup is valid (i.e., partially configured pipettes won't pickup too many tips). This is blocked in the tip selection UI, but the error can arise if saved steps are reordered, deeming unsuccessful their tip selections at the time of step creation.
…20022) # Overview The aspirate/dispense while tracking has to propagate the right type of overpressure error.
…#20288) Add logic for OT-2 collision detection that is now more pressing for 8-channel partial tip pickup. Previously, we had hard-coded in the logic for the Flex only (oops!).
## 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.
* fix(step-generation): fix range error
# Overview Unicode has several ring-like symbols: - `˚` is a diacritic mark, such as in `å`. - `°` is the degree symbol. We previously (PR #18369) fixed all the incorrect ring symbols, but more have snuck in since last time. ## Test Plan and Hands on Testing Run CI tests. ## Risk assessment Low.
# Overview Follow-up to PR #17331: Unicode has 2 different characters for mu: - `µ` (U+00B5) is the "micro" symbol, meaning 1/1,000,000th. - `μ` (U+03BC) is for writing Greek-language text. Using the Greek-language `μ` can cause ugly font fallback if a font doesn't have the Greek alphabet. We cleaned this all up last year, but since then, new Greek `μ`s have snuck into our codebase, mostly in the docs and release notes. ## Test Plan and Hands on Testing Run CI tests. ## Risk assessment Low. I'm adding this in RS 8.8.0 branch because the release notes are in RS 8.8.0.
The last 2 translations and a fix for the script so that `app/src/assets/localization/zh/index.ts` does not get deleted. Co-authored-by: Jesse Johnson <158077254+neo-jesse@users.noreply.github.com>
…oo (#20307) # Overview When we import a protocol, we upgrade its labware to the latest available versions. Protocols have an `__INITIAL_DECK_SETUP_STEP__: labwareLocationUpdate` section that looks like this: ``` { "uuid:opentrons/labware/1": "location" } ``` Often the `location` is a slot. But with stacking, `location` could also be the labwareID of some other labware. But in the implementation where we updated the labware versions, we only updated the keys of this map, but not the `location` values: https://github.com/Opentrons/opentrons/blob/cc11d93b785d95babd4e483fd0c1aacf7ae7230d/protocol-designer/src/step-forms/reducers/index.ts#L384 This results in malformed protocols where the `location` contains labwareIDs that no longer exist after migration. This also causes the `LabwareTemporalProperties.stack` to be malformed, causing problems like RQA-4935. This PR updates the labware version in `location` as well if `location` is a labwareID. Note that there are probably a bunch of protocols out there created before this fix that have broken references in `labwareLocationUpdate`. ## Test Plan and Hands on Testing Import Alex's protocol from the bug ticket. There is supposed to be a lid on the well plate in slot 3, but the lid is not visible without this PR. Also the "Materials list" page is malformed. And the exported Python protocol is very malformed. After this PR, we correctly show the lid on top of the well plate. And the protocol now passes analysis if you re-export it. ## Review requests Is there some better way to detect when `location` contains a labwareID? In this PR, I just attempt to split it on `':'` and try to look up the labware URI in the `labwareDefs`. ## Risk assessment Low.
…tion modal and timeline errors (#20318) This PR creates and wires up timeline errors for 1) too many tips picked up and 2) incomplete pickup in `pickUpTip` command creator according to designs. Also, it refactors the existing logic for rendering an error inline notification on saving a bad tip selection, and adds descriptive copy to the notification depending on the reason for the bad selection.
# Overview Adds meniscus relative pipetting actions to the 8.8 known overpressure issue (as opposed to just dynamic aspirate/dispenses). ## Test Plan and Hands on Testing ## Changelog one-line change to app release notes. ## Review requests ## Risk assessment low.
# Overview Add mention of partial tip configs to PD release notes: - single tips for Flex 96 and all 8 ch pipettes in PD 8.7 - add a mention of column for 96? may have been missed at one point in time? ## Test Plan and Hands on Testing ## Changelog one-line addition(s) to PD release notes. ## Review requests ## Risk assessment low.
…ional rendering (#20323) Automatically show selected tips error on mount if opening an existing step
…Exist for changeTip=never (#20328) # Overview I noticed that if you make a Transfer step as the first step in a protocol and choose tip handling = never, we show the `LABWARE_DOES_NOT_EXIST` error message: <img width="762" height="68" alt="image" src="https://github.com/user-attachments/assets/2b4d28bf-4f97-4d9b-b930-8784e3105081" /> This is not as nice as the more explicit `NO_TIP_ON_PIPETTE` error we used to have. Here's why this is happening: Previously, if you selected tip handling = never, we would use whatever tip rack you chose for this step, and continue onto step generation. Then in the `CommandCreator` for the first `aspirate` in the transfer, we would notice that there was no tip on the pipette, and emit a `NO_TIP_ON_PIPETTE` error. However, we realized that we were using the wrong tip rack for tip handling = never. We changed the implementation to use the tip rack from the previous step in that case (AUTH-2537). However, if this is the very first step on the protocol, then there is no previous step, and the tip rack would be undefined, triggering this error that says `This step tries to use undefined`. This PR fixes the code to emit the `NO_TIP_ON_PIPETTE` error again when tip handling = never and there is no previous tip rack: <img width="762" height="88" alt="image" src="https://github.com/user-attachments/assets/92db0d9b-b279-4dc3-8796-32991fa98c61" /> ## Test Plan and Hands on Testing Tried it locally with `make -C protocol-designer dev`. ## Review requests Is this worth getting into PD 8.7.0? It's a small quality-of-life issue, and I'd also be OK with putting this into `edge` instead. ## Risk assessment Low.
Resolved conflicts: - docs/flex/docs/touchscreen/quick-transfer.md
jerader
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wowza 🤩
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## edge #20331 +/- ##
==========================================
+ Coverage 25.58% 25.64% +0.06%
==========================================
Files 3640 3639 -1
Lines 303120 302778 -342
Branches 42327 42300 -27
==========================================
+ Hits 77552 77659 +107
+ Misses 225544 225095 -449
Partials 24 24
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
lol, @rclarke0 just checked in something and introduced more conflicts I have to resolve ... |
Resolved conflicts: - protocol-designer/src/assets/localization/en/alert.json - step-generation/src/constants.ts - step-generation/src/types.ts
0f5fcac to
1af7205
Compare
Resolved conflicts: - protocol-designer/src/assets/localization/en/alert.json - step-generation/src/constants.ts - step-generation/src/types.ts
1af7205 to
a68c88b
Compare
koji
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
components' change looks good to me.
This has all our changes from RS 8.8.0 and PD 8.7.0, and this will pull the RS alpha and release tags into
edge.