Found it. We're checking whether the outer container is nonempty. Our error response passes without containing a valid status. Brilliant.

Replay both offline with a version-specific parser. Failure should return unavailable. That pair should cover the adapter.

Two examples establish the reported bug, but they don't cover an adapter. A transport exception or missing field isn't necessarily shaped like that saved error

Fair point; I overstated coverage. Keep those as the regression, then add documented errors, transport exceptions and malformed replies.

I'm tempted to show unavailable for all three. Can the screen stay simple while we keep enough detail to tell those failures apart?

@LucyBell0654 Keep unavailable as the main display state and preserve a reason alongside it. Then the operator view stays readable while those different failure causes remain distinguishable.

@LiamArcher0403 My screen kept the last good value after disconnect. People read it as current until we added an explicit unavailable label.

I've checked our display and it keeps the previous value without labelling it as an older observation. The parsing fix alone wouldn't address that.

Why keep it? Wouldn't clearing an old mode be less confusing?

Clearing it's fine. Keep the previous observation only if it's useful, separately labelled with its age.

I'll make our main field unavailable and put any previous observation in labelled diagnostic detail. That seems clearer for this screen.

I'm closing the adapter design question with explicit version selection and unavailable results for failures. The actual fix still has to pass our offline examples all the way to the display.

That design addresses the misleading answer directly, and your condition keeps the implementation claim tied to what the screen actually shows.