refactor(api): Save and load tip length calibrations from tiprack uri

[Laura-Danielle]

Overview

This is an effort to fix the problem described in an escalations case here. Where the tip length data does not persist during a protocol run, but does in LPC. @SyntaxColoring discovered that it seemed to be a result of the labware hash not always being the same once a dict has been converted to/from a pydantic model. We both agreed that the easiest path forward would be to lookup tip length calibrations by labware URI instead.

Note

The decision was made to keep around tiprack hash for the delete endpoint until we decide to bump the version header of the API. A TODO was included in the endpoint.

Test Plan

• Without modifying tip length data on a robot, ensure that behavior does not change (i.e. robot moves to all the correct places).
• Modify the tip length calibration to be purposefully off (as described in the ticket) and verify that the tip length persists both in LPC and the protocol run.
• Delete tip length calibrations and start fresh. Ensure that behavior is normal.

Changelog

• Load and save tip length calibrations by tiprack uri rather than hash. If the old format is detected, we should automatically migrate the data shape.
• Updated relevant locations for the new data shape

Review requests

Check out the code and make sure everything makes sense to you.

Risk assessment

High. This is modifying a critical component of loading tip length calibration.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.74%. Comparing base (5172fc1) to head (6f2e232).

Additional details and impacted files

@@                   Coverage Diff                   @@
##           chore_release-7.2.0   #14512      +/-   ##
=======================================================
+ Coverage                67.72%   67.74%   +0.02%     
=======================================================
  Files                     2517     2517              
  Lines                    72107    72154      +47     
  Branches                  9291     9291              
=======================================================
+ Hits                     48835    48882      +47     
  Misses                   21052    21052              
  Partials                  2220     2220              

Flag	Coverage Δ
app	64.57% <ø> (ø)
g-code-testing	92.43% <ø> (ø)
hardware	57.54% <100.00%> (+0.24%)	⬆️
react-api-client	66.38% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files	Coverage Δ
...ngsCalibration/CalibrationDetails/OverflowMenu.tsx	81.13% <ø> (ø)
.../opentrons_hardware/firmware_bindings/constants.py	99.24% <100.00%> (+0.01%)	⬆️
.../firmware_bindings/messages/message_definitions.py	97.50% <100.00%> (+0.14%)	⬆️
...ns_hardware/firmware_bindings/messages/messages.py	91.66% <ø> (ø)
...ns_hardware/firmware_bindings/messages/payloads.py	95.88% <100.00%> (+0.23%)	⬆️
...t-server/robot_server/service/tip_length/router.py	96.42% <ø> (-0.24%)	⬇️

[sfoster1]

Looks good to me with the couple of small nits.

I think this is going to need a pretty broad testing pass and I'm not sure what the timing will be, so for now let's

• hold it open until we can test it on or after the 26th
• decide then whether it goes to edge or release

[SyntaxColoring]

This looks good. Various nitpicks and small suggestions as I get familiar with this.

[TamarZanzouri]

I agree with a few of Max's comment but besides that looks great!

[SyntaxColoring]

Sweet, this looks good, pending client-side changes (JS linting is currently failing). Thank you for taking this on. I'm very happy that we're moving away from the fundamentally problematic hashing instead of trying to patch it up.

I agree with you and Seth that we'll have to test this carefully on a robot. I'll do that as soon as I can.

[nusrat813]

Tested on OT2 refresh

• Tip lengths persisted in LPC and Run
• Tip length cals were able to be deleted