Our code takes the container as true. Then it fills a missing status with the last value.

Those are two bugs to test separately. Or two behaviours, until you establish what the screen was intended to promise.

What does the display show beside that last value? If its age and failed refresh are absent, an operator cannot distinguish an old observation from a current one.

We made stale explicit on another dashboard. Who owns this version's failure tests?

Louis, no age or failure indication. Omar, our application maintainer owns the tests. I supply saved responses.

Give the maintainer the expected display as well as the saved response. Otherwise the test can faithfully preserve your current mistake, now with the reassurance of a passing result.

I would keep last known availability for diagnostics. I would not label it current after a failed refresh.

Anil, I agree about retaining it. Gabriel, a separate last-success time would make that useful without forcing the failed request to produce an availability judgement.

Bench screen now distinguishes current, stale and unavailable. Failed refresh keeps an explicitly old value, not current availability.

Does first startup without any successful read show unavailable too?

Yes, tested that case. Invalid response shape also shows unavailable. Comparison against the controller is still pending.

Keep those examples with the SDK version and the display expectations when handing this over. Your bench result establishes the application's handling of those examples, not that every controller response has been interpreted correctly.