The replacement laptop returns a container from our FR5 status call where the old environment returned a value, and our dashboard treats any nonempty answer as success; who should decide what gets displayed when the request contains an error?
Start with the documented response for the exact library version. Is there a success or error field the display code is currently skipping? My first question would be what the application actually received on one failed request.
The wrapper documentation names a result flag and a data field; the programmer confirms the display currently checks only whether the returned object is nonempty.
I'd want to see its age and that the new read failed. Otherwise someone can mistake a retained number for a current one, especially when nothing on the screen changes.
Good catch by Caleb. Are you testing the old environment too, or replacing it completely? Two return formats could need different handling before they reach the same display.
What happens if a response has neither the expected fields nor a recognisable error? I would want that to display as unavailable or unknown, since a future library change could otherwise restore the same misleading green state.
Unknown responses now show unavailable, and the stored last-good value is labelled with its age; the offline examples pass for both documented formats.
The workshop check remains outstanding. At least we now have a failed response that fails visibly, an unexpectedly useful improvement for a status display.
Let the workshop user try it before closing the repair. They should be able to tell an old reading from a new one without remembering this conversation.