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.

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.

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

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

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.

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

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

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

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

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

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

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

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

Our display still needs a verified parser before I'll rely on it. The container check is a useful finding, not a completed fix.

Understood. Explaining the broken check isn't the same as having a parser you can trust across those responses.