Exactly that. Nonempty container passes, then the wrapper selects the field that looks like our old status.

Then the plausible number is an accident of parsing until the documented success condition and payload are checked; I'd replay those replies offline before changing anything at the controller

I've made a display look consistent by filling gaps from its last reading, then had to explain why it stayed so reassuring during a failed connection. Bruno, does yours retain a previous value as well, or is this only a wrongly selected field?

Would two explicit version adapters be easier to support than a parser that guesses which response arrived?

Anna, possibly, but I wouldn't decide the abstraction from one failing field. If both supported versions have different contracts, explicit adapters can help; one selected supported version may need only one clear parser.

Will the screen show whether that retained value belongs to the current connection?

Two defects may be involved, then. Invalid extraction creates a value that was never a successful read; retention presents an old successful read without its age. I'd test those independently so suppressing one doesn't accidentally make the other look fixed.

Nora and Anna, explicit supported-version handling sounds reasonable here, with unknown versions rejected clearly rather than falling through to whichever format happens to parse

Jane, yes. And share the normalised result contract above those adapters, so unavailable means the same thing to the screen regardless of which laptop supplied it.

I would preserve why it is unavailable too; an invalid response and a transport timeout needn't become the same mysterious blank in a later support report

Alex's connection question still needs an answer. On my display, the last value wasn't necessarily wrong as history. The misleading bit was making it look current just because the screen had refreshed.

Alex, no connection identity or age shown now. Last value can outlive a reconnect. That needs its own display rule.

Can the maintainer give the operator one understandable distinction between current, historical and unavailable, with the detailed failure reason retained for support? They should not need to decode an SDK error container.

And check the screen before its first successful read; there is no historical value to display then.

Version-specific parsers now reject failed-status payloads in replay. New screen state marks old values historical with age. First-read failure and reconnect still need tests.

That is useful progress, but don't describe the screen rule as fully verified yet. Replay a success followed by failure, a first failure, and reconnect with retained history. I'd inspect the displayed state at each step, not just assert that the parser raised no exception.