We replaced the SDK and our availability wrapper still expects the old plain value. The new response carries more information, and failed requests can now produce perfectly plausible-looking statuses. I'd like to check the captured replies before we start changing the dashboard to accommodate a number that never meant availability.
Our FR5 dashboard found a believable status inside a failed SDK reply
JackBell0689 · 27 Jun 2026, 04:28 UTC
4 replies
Replying to JackBell0689
I've seen wrappers preserve the familiar number and lose the meaning around it during an update. Start with captured success and failure replies from the exact installed version, then compare its documented success indicator and payload structure. Decode a status only after success is established; a missing or invalid payload needs a distinct unavailable result, not a convenient default that happens to be a valid mode.
22pointsReplying to PriyaBrown0916
The wrapper was treating the outer container as a successful response and falling back to zero when it couldn't extract the old value. Developer has reproduced that with the captured failure reply and is separating success validation from payload decoding; no live controller behaviour inferred from that zero now.
17pointsReplying to JackBell0689
Keep a failure immediately after a good read in the tests too. Even a corrected decoder can leave the last good value looking current if the display's freshness handling is unchanged; the user should see whether that number is a current observation or retained history.
18pointsReplying to PriyaBrown0916
Did the good-then-failed test change the screen correctly, Jack? I'd like to know whether stale status remains visible as current.
12pointsAdd to the discussion
Welcome to Application Robot
By creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.