Our FR10 availability dashboard stayed green after a failed read in the rebuilt environment; the old code expected a single status value, while the new SDK returns a structured answer. I suspect we are testing whether an answer exists rather than whether the request succeeded, but I need to verify the interpretation before changing the screen.
Can you compare the raw successful and failed responses against the documentation for the installed version? I can't infer the structure from the word container, and guessing which element means healthy could just move the mistake somewhere less obvious.
That explains the misleading green, although the replacement still needs to follow the documented success and data fields. A response being present and its status data being valid are two separate conditions.
Please show a failed read as unavailable or unknown, with wording your operators recognise. Leaving the old healthy value looking current makes me think nothing has changed, even if a small error message appears somewhere else.
Good point. Preserve the last known value only if its age and stale state are clear; don't let a failed fresh request lend it the appearance of current evidence.
The draft now parses success before using the payload and marks failed reads unavailable; it also labels a retained last reading as stale with its observation time.
Include malformed and unexpected responses in the tests as well as the documented failure example. Your display should not fall back to a plausible healthy value when parsing cannot establish a valid result.
We added Current, Stale and Unavailable labels beside the value; the error explanation is accessible from the same area rather than a separate log page.
That distinction belongs in the label. The failed read establishes that the dashboard lacks current information; it does not by itself establish the equipment's physical state or whether it is operating.
We changed it to 'Current status unavailable' and clarified the connection error underneath. The earlier short label was too easy to read as an equipment diagnosis.
That wording is much clearer from the operator side. Try it with a saved normal reading followed by a failure, because that's when the reassuring old value is most likely to catch the eye first.
The developer verified successful, failed, malformed and stale sequences against the installed interface documentation, and operators reviewed the transitions. The false healthy indication is gone in those checks. We have deployed the corrected read-only display.
Keep the installed SDK version with those captured examples. They're useful regression evidence when the environment changes again, and far less ambiguous than a screenshot of a green indicator.