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

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.

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.

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

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.

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

Is there a reason to retain the old value at all? Clearing it sounds less confusing for a mode display.

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

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

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

@MeiChan1125 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?

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

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

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

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