fix(app): fix stale failedCommand during Error Recovery

[mjhuff]

Closes RQA-2936

Overview

Recently, we added functionality to "retain" the failed command, so the app has the ability to show certain things even after the server no longer currently recovers from a failed command.

The exact dependency array used to update the retained failed command didn't properly account for the exact command, so sometimes you'd enter error recovery with a stale command the second time you entered error recovery. This fixes that and cleans up some of the memoized labware calculation utilities, which weren't completely correct either.

Test Plan and Hands on Testing

• Verified correct behavior according to the protocol/steps in the linked ticket.

Changelog

• Fixed the Error Recovery tip selector not always showing the correct well from which to pick up tips.

Risk assessment

low

[SyntaxColoring]

TY!

[SyntaxColoring]

This is a React idiom question, I think:

Would it not be safer for the useEffect dependencies to be failedCommandByRunRecord (the object reference) and protocolAnalysis (the object reference)? And then some memoization thing elsewhere ensures that those object references change when, and only when, the object contents change? Is that even possible?

I ask because it seems easy to miss a dependency when we list out specific scalars like this.

[mjhuff]

Yeah, good question. To question #2, It is possible. To question #1, in general, I don't see this done elsewhere, and my guess would be that:

• It's more code to maintain and reason about.
• You still have the base problem of thinking about what causes a re-render, and now it exists apart from the useEffect.
• It's arguably less efficient.
• ESlint has a react-hooks plugin that gives us a rough idea of what dependencies we should think about adding/exclude. It's not perfect, but it's at least there.

But yes, it's incredibly easy to miss dependencies, and that's why I think a lot of React developers hesitate every time they think about reaching for useEffect.