I need our dashboard to admit when it has no current reading. Since the environment change, the wrapper finds a number inside the SDK reply and shows it as status even when the request failed. The new reply has several fields. Where should the check live so the screen cannot make this mistake again?
Put the response interpretation in one adapter tied to the SDK version you're using. Check the request outcome before extracting the documented status field. I would test it with saved replies first; no need to involve the whole cell to catch a parser choosing the wrong number.
The developer found the wrapper taking the first element it could turn into an integer. We have replaced that with the documented field lookup. A saved failed request now gives unavailable, not a status.
And try a successful request with the status field absent. I caught a similar hole recently: the outer reply looked fine, then the wrapper supplied its own cheerful default.
Keep any previous reading visibly old, RosaBrown. The person checking the bench should not need to inspect the log to discover that the large status label is no longer current.
Both cases pass now. After failure the current field is unavailable; the last successful reading sits separately with its age. Missing status and unknown response shape also show unavailable. The maintainer tested startup, failure after success and recovery to a new success from the normal shortcut.
Yes. Export uses the same adapter result and identifies the retained reading separately. We compared the screen and exported rows through those cases after restarting the workstation. The maintainer has the restored environment and test examples; this one is closed.