fix(robot-server): Fix 500 error trying to start tip length calibration sessions

[SyntaxColoring]

Overview

Closes RSS-349.

Test Plan

• On an OT-2, follow the reproduction steps in RSS-349 and make sure you can complete tip length calibration now.

Fix details

According to our labware definition JSON schema, these are the valid shapes of gripperOffsets:

• Totally omitted:

  <gripperOffsets omitted>
  

• Containing just default:

  {
      "default": {
          "pickUpOffset": {"x": 1, "y": 2, "z": 3}
          "dropOffset": {"x": 1, "y": 2, "z": 3}
      }
  }

• Containing default and slot-specific offsets:

  {
      "default": {
          "pickUpOffset": {"x": 1, "y": 2, "z": 3}
          "dropOffset": {"x": 1, "y": 2, "z": 3}
      }
      "A1": {
          "pickUpOffset": {"x": 1, "y": 2, "z": 3}
          "dropOffset": {"x": 1, "y": 2, "z": 3}
      }
  }

The problem was that this line in our Pydantic model did not match that.

opentrons/shared-data/python/opentrons_shared_data/labware/labware_definition.py

Line 317 in 76a6e54

default_factory=dict,

It would cause the server and local analysis engine to return labware definitions where gripperOffsets was normalized to {}. This was invalid according to our JSON schema, which required gripperOffsets to either contain at least a "default" key, or be totally omitted.

Those incorrect {}s are all over the database by now, so we unfortunately can't correct the Pydantic model to match the JSON schema. Instead, we need to loosen the JSON schema to accept what the Pydantic model has been emitting.

So, we're loosening the JSON schema to now accept these additional shapes:

• Containing nothing:

  { }

• Containing just slot-specific offsets (this is an accidental byproduct of this implementation, but we believe it to be harmless)

  {
      "A1": {
          "pickUpOffset": {"x": 1, "y": 2, "z": 3}
          "dropOffset": {"x": 1, "y": 2, "z": 3}
      }
  }

Review requests

Is this the best way to fix this?

Does it look like our Pydantic model now conforms to our JSON schema?

Risk assessment

Low I guess? I tried not to touch any of the logic for deciding gripper offsets.

[codecov]

Codecov Report

Merging #13607 (e3ca563) into chore_release-7.0.0 (ae74b67) will not change coverage.
The diff coverage is n/a.

Additional details and impacted files

@@                 Coverage Diff                  @@
##           chore_release-7.0.0   #13607   +/-   ##
====================================================
  Coverage                71.33%   71.33%           
====================================================
  Files                     2423     2423           
  Lines                    68162    68162           
  Branches                  7937     7937           
====================================================
  Hits                     48620    48620           
  Misses                   17687    17687           
  Partials                  1855     1855           

Flag	Coverage Δ
app	68.99% <ø> (ø)
g-code-testing	96.44% <ø> (ø)
labware-library	49.17% <ø> (ø)
notify-server	89.13% <ø> (ø)
protocol-designer	46.09% <ø> (ø)
shared-data	74.33% <ø> (ø)
step-generation	86.82% <ø> (ø)

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

Files Changed	Coverage Δ
api/src/opentrons/protocol_engine/state/labware.py	100.00% <ø> (ø)

[sanni-t]

Looks great! I like the integration test idea too

[sanni-t]

This is pretty cool!