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.

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

Fair point. Those two are a regression case, not full coverage. The adapter also needs documented error cases, transport exceptions and malformed responses exercised.

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

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

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.