@DineshAli0212 I've checked our saved examples. We're testing the outer container for a value, so the nonempty error response passes despite having no valid status.

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

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

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

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

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?

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

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

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

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

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

@TheoBarnes0584 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

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.

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