The replacement SDK returns a container where our read-only training dashboard used to expect one status value. A failed request still produces a plausible availability display. I want the adapter to establish what the reply means, not find a reassuring value somewhere inside it.
What exactly came back on failure, and how did your code turn it into availability? I wouldn't infer success from a nonempty container, but I'd like to see the actual mistake before prescribing a decoder.
The adapter tests whether the whole returned object is truthy. A failure response is still a nonempty object, so it becomes available. It never checks the documented result field.
I would keep the last successful reading separate from the current request state. We had a screen that retained a useful old value but made it look current, which was a different error from decoding the reply wrongly.
They could not reliably tell in the first version. The time was present but poorly named, so I would test the meaning with a reader rather than assume adding digits fixes the problem.
For the decoder, use examples tied to the installed SDK version and check its documented success condition before interpreting the payload. Unknown shapes should be explicit failures of interpretation, not another route to available.
Our draft now starts with no current reading. Failed requests show unavailable, and any previous good value is labelled separately with its successful-read time. The adapter changes are in offline checks only.
Does unavailable describe the controller itself or the ability to obtain a current reading? Those are different claims for the person deciding whom to call.
The current reading, not proven controller unavailability. Good catch, Theo. I have changed the wording to current reading unavailable so a communication failure isn't presented as a controller diagnosis.
Hana, have you tried a successful reply followed by an unfamiliar one? That sequence would show whether an interpretation error accidentally leaves the old current-state label visible.
That offline sequence now marks the current reading unavailable and preserves the old value as historical. Unknown method calls fail too. Reconnect and slow-response behaviour still need tests.
Then your decoder has improved under the tested cases, while freshness handling remains unfinished. I would keep those two statements together in the handover instead of marking the dashboard fixed.