fix(app,robot-server): Account for failed commands not having a pipetteId

[SyntaxColoring]

Overview

Closes RQA-3599.

Test Plan and Hands on Testing

• Manually do some GET requests to /runs/{id}/currentState throughout a run and watch the new tipState field change over time. Make sure it's correct.
• Follow the steps to reproduce in RQA-3599 and make sure the user-observable behavior is fixed.
• "There is absolutely no way there is a regression" – @mjhuff

Changelog

• Expose the robot's idea of whether there's a tip logically attached, via the GET /runs/{id}/currentState endpoint.

• Use that to replace some code in the frontend that was reading command-level information to try to get the pipetteId involved in an error.

  That code could not account for gripper failures, where the failed moveLabware command does not have a pipetteId. That's what was causing RQA-3599.

Review requests

See comments below.

Risk assessment

Low?

[SyntaxColoring]

@TamarZanzouri Is this a good idea, or does this conflict with any future vision you had for the orchestrator stuff?

[SyntaxColoring]

DIscussed in-person. I think we're both a little confused about this, but:

RunOrchestratorStore is largely a glorified RunOrchestrator | None variable. And from that perspective, yes, all of these methods are redundant boilerplate, not offering any abstraction. We can replace RunOrchestrator.foo() with RunOrchestrator.run_orchestrator.foo() without losing anything.

There is then a question of, well, why even have RunOrchestratorStore. The answer is that other than all of these wrapper methods, it also provides access to a "default RunOrchestrator" for the "stateless command" endpoints, and it gates that access behind there not already being some other, run-controlled, RunOrchestrator already active. That is a good thing for the server to do, but I wonder if it still makes sense at this layer, now that we have maintenance runs. We might want one higher-level thing mediating between runs, maintenance runs, and stateless commands.

[sfoster1]

Yeah stateless commands are not a thing we use anymore I'm pretty sure - we replaced them with maintenance runs because it turns out we need state for most stuff we want to do.

[sfoster1]

Looks good to me and makes sense.

[sfoster1]

Yeah stateless commands are not a thing we use anymore I'm pretty sure - we replaced them with maintenance runs because it turns out we need state for most stuff we want to do.