…aM (#14839)

closes AUTH-23

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.

…4835)

closes AUTH-2

…14842)

closes AUTH-311

…14841)

closes RQA-2490, AUTH-269

…4753)

<!--
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

…14849)

Closes RQA-2428

)

closes RQA-2553

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

closes AUTH-313

#14850)

…te multiple tipracks

closes AUTH-314

* 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

)

closes AUTH-121, AUTH-122, AUTH-224, AUTH-320

The schema changes in edge weren't in release and need to be manually
merged.

Closes RQA-2558

…ng commands exist (#14857)

closes AUTH-267

<!--
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

Calculates module ramp rates based on run log and uploads to google
sheet.

# Test Plan

Ramp rate script tested on all three modules with different robots. 

# Changelog

Created module ramp rate script to find ramp rate runs in run log folder
and upload ramp rates to abr-run-data sheet
Also changed IP address in error recording to a user input rather than
an input in order to allow the command to be created into a desktop
shortcut.

# Review requests

<!--
Describe any requests for your reviewers here.
-->

# Risk assessment

…4870)

closes AUTH-8 AUTH-9

* fix(app): remove unnecessary console.log

…tton text (#14872)

closes AUTH-319

…14866)

Adds the runtime parameter definitions to the run summary for both current and non current runs, accessible via the GET /runs and /runs/{run_id} endpoints.

Closes EXEC-387

Closes RQA-2561

…) and request_pause() (#14879)

# Overview

This fixes something that keeps confusing me as I work on EXEC-382.

Various things state that `ProtocolEngine.stop()` takes effect
immediately—meaning, to me, that the robot's motion is stopped
immediately, the protocol exits immediately, and the HTTP run is marked
as `stopped` immediately. This does not seem true. It merely puts the
run into a `stop-requested` state, which only later settles into a
`stopped` state.

This PR adjusts some docstrings and renames `stop()` to
~~`stop_soon()`~~ `request_stop()`. ~~The name `stop_soon()` is inspired
by asyncio and anyio's `call_soon()`.~~ `pause()` has the same caveat,
so it's renamed to `request_pause()` for consistency.

# Test plan

None needed.

# Review requests

* ~~Taking for granted, for a moment, that the `ProtocolEngine`
interface has to work like this: is `stop_soon()` a good name? Maybe
`request_stop()` would be better?~~ Done.
* ~~`pause()` has the same caveat. Do we want to rename that too, for
consistency?~~ Done.


# Risk assessment

No risk.

* feat(opentron-ai-client):  add Side Panel component

* fix(app): update software keyboard ref type

…otocol reanalysis (#14878)

closes AUTH-118

…via advanced settings. (#14832)

…zation provider (#14741)

implements a localization provider for the ODD app that substitutes
anonymous translation values when the "enableOEMMode" robot setting is
on. pushes the localization provider further down the DOM to be within
the ODD api host provider for the robot settings request, and splits out
a separate instance for the desktop app.

refactors the `OnDeviceDisplayApp` component a bit to avoid rerenders of
providers - currently the entire ODD app rerenders on every route change
because of the scroll ref.

refactors the initial loading screen out of the route tree and up the
DOM to block localization provider render until the robot-server api is
up

adds api client and react api client functions for robot settings get
requests.

all translation keys that reference "opentrons" or "flex" are moved to
the new `branded.json` and `anonymous.json` files. anonymous copy will be finalized in PLAT-243

closes PLAT-265

…ate variable names (#14888)

…rotocol (#14885)

Closes AUTH-317

# Overview

Adds a max-analyses-per-protocol limit of 5 analyses. Auto-deletes the
oldest analysis (es) before adding a new one if the number of analyses
stored exceeds the max.

# Risk assessment

Low. Well tested and pretty isolated feature.

…hange the userspace boot screen. (#14865)

…her (#14890)

closes AUTH-340

Closes EXEC-393

Flex automatic tip drop behavior at the end of a run is different from the OT-2: it keeps tips attached while the OT-2 drops them. The drop-tip wizard entry modals do not reflect this per copy, so update the copy.

# Overview

Fully anonymize all localization strings and finalize copy.

Addresses PLAT-243

# Test Plan

None. Unit tests to come later.

# Changelog

- Removed nearly all mentions of "Opentrons" in strings. (Only one left
is for OT-2 tip length calibration.)
- Some very light edits elsewhere, also updated in "branded" strings.

# Risk assessment

minor, but it's not trivial to QA all of these changes in situ

# Overview

Create RobotContextTracker class.

This class provides a `track` method. 
The track method should be used as a decorator on either a
function/method. It takes a RobotContextState enum value to label what
state the RobotContextTracker is tracking. Uses `FunctionTimer` to
measure execution time and stores results in a list.

RobotContextTracker is defaulted not to track anything at all. To turn
on tracking, instantiate the class with `should_track=True`. When not
tracking, the `track` method calls the underlying wrapped function as
quickly as possible.

# Test Plan

- See test_robot_contest_tracker.py

# Changelog

- Add RobotContextTracker class
- Add test_robot_context_tracker.py

# Review requests

None

# Risk assessment

Low, not being used on any production code

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]>

…es length bug (#14904)

Closes AUTH-347

# Overview

#14885 added the feature to limit number of analyses we store in DB. In
[this](#14885 (comment))
comment, @SyntaxColoring pointed out that we should consolidate the DB
transactions for better performance, so that's what this PR does.

Also fixes a bug where if the existing number of analyses in the DB was
3 and we were to add another analysis, then the formula for getting the
analysis IDs to delete would result in `analysis_ids[:-1]` and it would
delete all analyses except last one.

# Test Plan

- Tested the cases mentioned in #14885 
- Tested the bug case

# Risk assessment

Low. Refactor + small bug fix

* refactor(components): refactor StyledText stories

* refactor(components): refactor location icon stories

* refactor(app): refactor externallink stories

* refactor(app): refactor banner component stories

For some reason I changed this to be pattern= when updating pydantic,
but that's still wrong and still needs to be regex.

Closes EXEC-397

* feat(opentrons-ai-client): add prompt guide component

…d document `actions` list as empty (#14905)

fix PLAT-173, PLAT-228, PLAT-271

…k configuration (#14684)

Build out the backend and frontend to support loading modules into the
deck configuration, including tracking modules by serial number in the
persistent deck configuration directory.
Closes RESC-209, PLAT-247, PLAT-248, PLAT-249, PLAT-250, PLAT-251, PLAT-252, PLAT-254

---------

Co-authored-by: Brian Cooper <[email protected]>
Co-authored-by: ahiuchingau <[email protected]>

…ating runtime parameters (#14903)

)

closes RQA-2517

adds the desktop advanced setting toggle to enable factory mode.

closes PLAT-280, PLAT-282

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]>

# Internal release notes

Get in the habit of updating these notes, even if only to create the
comparison URL. Most often I expect these notes are not worth the effort
but for stable internal releases will be a nice way to list what is
tested.

…pItem (#14900)

closes AUTH-300

…is busy (#14916)

closes RQA-2570

#14917)

…stom labware

closes RESC-243 and RQA-2573

Closes EXEC-186

If the gantry is not homed and a powercycle occurs, drop-tip wizard cannot proceed with flows. An error is raised during the flow, and ultimately a home command is dispatched that has the side effect of potentially aspirating liquid into the pipette, damaging it. We special case home errors to prevent this. 

The primary functional difference is now that any time an error occurs, exiting the wizard via the header should not home the gantry. Homing as a result of an error should only occur when the "Confirm removal and home" button is presented and clicked.

closes RQA-2279

#14918)

…ocation dropdown

closes AUTH-348

…ng (#14920)

enableOEMMode isn't really an internal_only setting, and we need it
included in the robot settings api response. change needed for the ODD
text to anonymize and the factory mode toggle to work. originally part
of oem-mode-integration branch.

# Overview

Closes https://opentrons.atlassian.net/browse/EXEC-406

Use a timing function universal to Windows, Mac, and Linux when running
on Windows and Mac
This will allow performance metrics tests to run locally for devs
The production implementation will always use Linux

# Test Plan

- Create test that patches _get_timing_function to return universal
timing function and make sure that works
- Realized I missed timing synchronous functions so I added that too


# Changelog

- In robot_context_tracker.py create a _get_timing_function which
imports the correct package based on os

# Review requests

None
# Risk assessment

low

fix PLAT-174

…#14925)

closes RQA-2578

…p routine (#14725)

Fixes various ongoing issues building versions into the system. This is
a follow-on to #14844 (61b1371)

- vite `define` config the way we do it does not hang the defined values
off of props of `global` explicitly (or maybe us injecting
`'globalThis'` into `global` breaks it) so use them as true globals,
altering the way they're accessed and the way they're declared in the
typings.
- i guess you don't actually have to do type imports in the top level
typings? removing the type import of the ipc bridge in the app-shell and
app-shell-odd global.d.ts fixed that issue. don't know why
- the ESM import for the script that updates the releases.json was wrong
which breaks some update stuff

## Testing
This is a bit annoying to test.

You _must_ test this on a compiled app package. You _cannot_ test this
on a dev build.
On a compiled app package,
- [x] the version should display in the settings tab of the app
- [x] you shouldn't have warnings about `include` on undefined in your
app logs
- [ ] you should get robot update prompts when you use an
internal-release build and connect to a robot running 1.3 or previous;
you should get robot update prompts when you use a release build and
connect to a robot running 7.2.1 or previous (note: couldn't test this
in time but the rest of it works)
- [x] the help menu should have a bugs url that works (the "report an
issue" button; it should pop a browser tab)
- [x] the help menu should say "View Opentrons App Logs" or "View
Opentrons OT-3 App Logs" as the variant demands
- [x] it should NOT say "View App Logs". that means the package name
wasn't properly interpolated.

I haven't dev-tested the second part because on my home setup making a
full compiled app package is broken for some reason, and you can't
actually run the node side in dev
This once more,
Closes EXEC-385 
Closes RQA-2579

# Internal release notes

* feat(opentrons-ai-client): add ChatDisplay component

* chore: add test workflow for opentrons-ai-client

closes AUTH-331

…14859)

closes AUTH-328

This PR add max flow rate values to each GEN2 and GEN3 pipette model
definition to be used for FE applications.

Rather than having a max flow rate for every pipette's supported tip's
volume for aspirate and dispense, we have only 1 max flow rate for every
pipette's supported tip that is. That value is based off of the lowest
volume minus 2% to account for safety.

For example:
`p1000_single_v3.6` has a `minVolume` of 5uL. The `t50` tips has a max
flow rate at volume 5uL of `801.3`. So the `uiMaxFlowRate` value is 98%
of that which is `785.2`

🔈 Additionally, the `lowVolumeDefault` default flow rates for
`aspirate`, `dispense`, and `blowout` have been changed to match the
`uiMaxFlowRate`. This DOES NOT result in a physical change behavior and
the change is needed for ui purposes.

# Overview

Closes https://opentrons.atlassian.net/browse/EXEC-407

We do not want performance-metrics to be a required dependency for the
publicly available opentrons package on PyPI. But we want to utilize
performance-metrics when running the opentrons package on the robot
itself.

The issue is, that since the performance-metrics package uses decorators
to track running code, the decorators will always need to exist. This PR
handles the case where the performance-metrics package does not exist
and injects stubs where necessary.

# Changelog

- Created the `SupportsTracking` mypy Protocol to define an interface
both `RobotContextTracker` and the stubbed class, `StubbedTracker`
implement
- Added performance-metrics as a dev dependency so tests using
performance-metrics can still run
- Created `performance_helpers.py`
  - Contains `StubbedTracker` defininition
- Handles loading `StubberTracker` if performance-metrics library fails
to load
- Provides `_get_robot_context_tracker` private singleton function for
eventual public-facing functions to use.

# Test Plan

- Testing to ensure stubbed `track` decorator returns the decorated
function unchanged
- Validate singleton logic of _get_robot_context_tracker

# Risk assessment

Low, still not actually being used anywhere

---------

Co-authored-by: Jethary Rader <[email protected]>
Co-authored-by: Jamey Huffnagle <[email protected]>

* fix(opentrons-ai-client): apply GlobalStyle to the application

closes AUTH-311

closes RQA-2572

# Overview

Follow up to #14935

This PR explicitly installs udev before calling make setup in the
components CI workflow. This is required to do a full make setup because
our usb bindings need it.

Hopefully closes
[AUTH-331](https://opentrons.atlassian.net/browse/AUTH-331) but I need
to push another tag to verify

# Risk assessment

Low

[AUTH-331]:
https://opentrons.atlassian.net/browse/AUTH-331?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ