refactor(app): Use currentState for tip detection

[mjhuff]

Overview

After completing a run or during Error Recovery, the app runs tip detection logic to determine whether or not to pop the drop tip wizard. It does so by iterating through protocol analysis, keeping track of attached pipettes, and looking at specific tip exchange commands to determine whether a not a pipette has tips attached. While this approach works, it's both brittle (any changes to tip exchange commands breaks the logic) and also a command scanning operation.

Now that we have tip status on our new /runs/:runId/currentState endpoint, we have a more robust option for determining tip status. There's one caveat: the robot and this util do have ideas of when a tip should be considered attached. On the app, because we want to show drop tip wizard when there might be a tip attached, such as during a failed pick up tip command, we assume there is a tip attached. In this instance however, the robot server does not think a tip is attached. Unfortunately, there's no way around manually accounting for these differences, but luckily they are few, and it's still a significant improvement over tracking every tip exchange command.

There's another optimization we can make too: we don't actually need to poll /instruments for pipette data, because now, the only place we use that data is during the tip detection util. Instead, we can fetch it along with the other necessary resources when determineTipStatus is invoked.

In short, these changes give us:

• Much easier to reason about tip detection logic.
• Significantly less brittle.
• No command scanning.
• No /instruments polling.

See "Review Requests" for the big question.

Test Plan and Hands on Testing

• Ran a bunch of drop tip CTA prompting in and out of Error Recovery on both the desktop app and ODD. Verified the modal prompts/doesn't prompt as expected.

Review requests

• @sfoster1 , Do we want this in 8.2? I think it's pretty easy to reason about, and all changes are contained to the tip detection logic itself, but I understand either way.

Risk assessment

-medium. This does change tip detection logic, but it's pretty easy to reason about now.

[sfoster1]

I do not think we want this in 8.2 unless we have to create another alpha for other reasons, and maybe not even then if it increases the test surface for the alpha.

[sfoster1]

Looks great and much more stable! I think that should be in resources though.

[sfoster1]

nit: this depends on the robot and uses api-client methods. IMO this should be in resources, not local-resources, which is only for stuff that doesn't hit the robot at all

[mjhuff]

Ahhhh yep, thanks!

[SyntaxColoring]

TY!

[SyntaxColoring]

Since pipetteInfoById is sourced from the run record, and pipetteId is sourced from the currentState endpoint, and those are two separate network requests, is there any danger here of this index not being present? Like if a new pipette is loaded, and the frontend receives an update to currentState before it receives an update to the run record?

[mjhuff]

In terms of network requesting, the requests occur simultaneously, so I don't believe so.

It is possible that we determine tips are attached to a pipette, and then the user ignores the drop tip CTA, decides to remove the pipette without any sort of detach flow, then places on a different one while the drop tip CTA prompt is up, but I'm ok with the app breaking in this spot.