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.

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

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

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

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

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

@MayaArcher0388 Ours does that too. No old-observation label. Fixing the parser would still leave that misleading value sitting there.

@RaviChen1172 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 use unavailable in our main field. Previous observations can sit in labelled diagnostic detail; that's clearer here.

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

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

That's a sound selection point. Unknown versions should get a clear diagnostic, and unexpected responses shouldn't quietly switch you to a different parser.

What if the optional details are empty but the status is valid? Could strict parsing incorrectly turn that into unavailable?

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

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

@PriyaCarter1003 I'll test both separately. Our nonempty check flattened those distinctions into one boolean. No wonder this got confusing.

I've got an answer to the design question: parse the documented status for the identified SDK and keep failures unavailable. I'll call the display fix complete only when our offline examples show that behaviour on screen.