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

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

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

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

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

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.

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

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

Both of our environments identify the SDK they load. That gives me an explicit selection input instead of guessing from a response.

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

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

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

@LeahBrooks0843 My success fixture had empty optional details. Keeping it stopped us tightening validation until perfectly valid answers failed.

@LeahBrooks0843 Those will be separate cases in my replay. The old nonempty check flattened both questions into one boolean, which explains quite a lot.

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.