feat: show OT-2's IP addresses even when the robot server is down

[SyntaxColoring]

Overview

Normally, the Opentrons App finds an OT-2's IP address by interrogating the OT-2's robot server.

When the robot server goes down, this mechanism fails, and we can't see the OT-2's IP address. And without that IP address, it's usually impossible to debug the problem that caused the robot server to crash in the first place.

There ways of finding the IP address that don't depend on the robot server being up. We should fall back on one of them.

From @mcous:

[The IP address display] in the app is fed by GET /networking/status, so like a lot of other places in the app, it sort of of naively gets disabled if the server goes down (and/or will never be populated if the server was never up).

The IP address information from the Discovery Client in the app is definitely of lower quality / confidence, but can def still be slotted in somewhere

Steps to reproduce

On v3.19.0...

1. Connect to your OT-2.
2. Confirm that the Opentrons App shows your OT-2's IP addresses.
3. Via SSH or a Jupyter terminal, run systemctl stop opentrons-robot-server.
4. Wait for the Opentrons App to show the “your robot’s API server is not responding” error.
5. Close and reopen the Opentrons App.

Current behavior

After step 5, the Opentrons App does not show the IP addresses of the OT-2 with the halted opentrons-robot-server.

If you omit step 5, it does show the IP addresses, despite the "your robot's API server is not responding" error. I'm not sure if that's because the Opentrons App can fall back to an in-memory cache, or if it's actually able to continually update them.

Expected behavior

Tn OT-2's IP addresses should still be displayed in the Opentrons App, despite the "your robot's API server is not responding" error.

More generally: whenever the Opentrons App is confident that it knows an OT-2's IP address, it should display it. For example, perhaps: when the OT-2's update server is unreachable, but the app is still hearing from its mDNS service.

[SyntaxColoring]

We sometimes work around this by sending customers the standalone discovery client CLI program. This works, but it's error-prone and kind of painful to communicate, so it invites a bit of extra back-and-forth.

[mcous]

With #6193, the error banner now displays the IP address that the app is attempting to use to connect to the robot. Is that satisfactory to close this issue? Not to say this UI doesn't need (and won't get) more work

[SyntaxColoring]

Probably, but can you clarify which error banners do and don't show the IP address?

[mcous]

If the robot-server is unhealthy (GET /health returns non-2xx, which should also imply GET /networking/status is also not returning successfully), there will be an error banner. This error banner will show the IP address that the app is attempting to use for that robot at that time

[SyntaxColoring]

So, today, we have at least a couple different banners:

• "Your robot's API server is not responding."
• "Your robot is advertising its IP address but not responding to requests."

And each of these corresponds to a different flavor of unreachability.

My understanding is that, in v3.20, this will still be the case. The wording will change, but there will still be several different flavors of unreachability, each with its own distinct error banner.

I want to confirm whether all of those banners show the IP. For example, if:

• The IP is shown in the case equivalent to "Your robot's API server is not responding."
• The IP still isn't shown in the case equivalent to "Your robot is advertising its IP address but not responding to requests."

Then I would want to keep this feature request open to track that remaining work.

From your comment, and a brief glance at the new code, it seems like the IP is always meant to be shown. Is that right?

[mcous]

So, today, we have at least a couple different banners... From your comment, and a brief glance at the new code, it seems like the IP is always meant to be shown. Is that right?

Sorry, should've been more explicit; these "different" banners from a code standpoint are a single banner with different copy displayed depending on the exact health state, so that's what was in my brain. The IP address will be displayed in all versions of the connectivity warning banner