fix(app, shared-data): app crashes when using python apiLevel<2.16 with fixed trash

[TamarZanzouri]

Overview

closes EXEC-759 - fix render deck map when trash is fixed (python api version < 2.16).

Test Plan and Hands on Testing

upload the following protocol without labware on the deck:

from opentrons import protocol_api, types

metadata = {
    "apiLevel": "2.15",
}

requirements = {
    "robotType": "OT-3"
}

def run(ctx: protocol_api.ProtocolContext) -> None:
    tip_rack_50 = ctx.load_labware("opentrons_flex_96_filtertiprack_50ul", 4)
    ctx.move_labware(labware=tip_rack_50, new_location=5, use_gripper=True)

1. enter ER
2. select manually remove labware
3. make sure that after the count down the app is not crashing.
4. make sure deck map is rendering.

tested deck map locally - works as expected.

Changelog

fixed but when using deck map with fixed trash with python protocols bellow 2.16.
added shared-data method to get fixed trash definition

Review requests

changes make sense? did I forget anyhing?

Risk assessment

low

[sfoster1]

some code style comments that rise into sort of alarm levels when I note that the code that was there before your PR is doing a full command list scan every time through the reduce...

[sfoster1]

Wait does this mean we're doing a full command array scan for every reduce callback here? Can we instead do something like

• hoist const protocolLabwareDefinitionsByUri = getLoadedLabwareDefinitionsByUri(...) to like line 261, outside of this reduce
• factor this logic into a function like

const getLabwareDefinition = (uri: string) => { 
   if (lw.id === 'fixedTrash) {
      return getFixedTrashLabwareDefinitionsByUri(lw.definitionUri)[lw.definitionUri]
   } else {
      return protocolLabwareDefinitionsByUri[lw.definitionUri]
   }

which preserves constness, and then call that function in the reduce?

[sfoster1]

if we do my comment above, this doesn't have to work the same way as getLoadedLabwareDefinitionsByUri() and can just return the definition directly instead of a one-element computed-key object

[mjhuff]

Yeah, the major issue is definitely my fault here. I think Seth covered everything, we need to hoist out the command scanning util. My one comment shouldn't apply if you use his recommendation for how to refactor getFixedTrashLabwareDefinitionsByUri. Thanks for doing all this!

[mjhuff]

Seth's approach should solve this, but if we do end up needing some sort association of the lw to the actual definitionUri, we should validate that the lw is a fixedTrash within the shared-data util itself.

[mjhuff]

Actually, we do this same nested iterative check on L208, so if you could move that outside of the reduce using the same aforementioned logic, that would be great!

EDIT: To clarify, it would probably be best to invoke this only once outside of BOTH getRunCurrentModulesInfo and getRunCurrentLabwareInfo and pass a memoized value of the labware defs to those functions.