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

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

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

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

@LiamChen1186 Can our screen just say unavailable, but retain the reason?

Yes. One unavailable display state, distinct reasons in the result

@LiamChen1186 My setup kept showing its last successful value when the connection failed. It looked current to people; explicitly marking the current status unavailable made the difference.

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?

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

I'll use unavailable in our main field. Previous observations can sit in labelled diagnostic detail; that's clearer here.

@LiamChen1186 How do you select the parser? Guessing from reply shape brings the same mistake back.

Our environments identify their loaded SDKs. I'll select from those.

Use those IDs. Reject unknown versions clearly, and don't switch parsers just because an unexpected reply resembles another supported format

@LiamChen1186 Empty optional details, valid status. Would strict parsing reject that too?

Optional can be absent where the contract allows. Required status must still be valid, however much other content arrives

On my setup, one success example had no optional details. Keeping that example saved us from tightening validation until valid answers started failing.