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

@ImranAli0218 Start a narrow parser for this version and replay your two examples offline. Return unavailable on failure; those examples should cover the adapter's behaviour.

That covers this bug. What about a transport exception or missing field? Neither has to look like your saved error

Fair point. Those two are a regression case, not full coverage. The adapter also needs documented error cases, transport exceptions and malformed responses exercised.

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

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.

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

@JamieCarter0991 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.

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

You can clear it. Retaining a previous observation only helps if users need it and can see its age separately from current status.

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