Why does our FR5 dashboard look healthy when its request fails?
AnnaBell0677 · 16 May 2025, 02:39 UTC
14 replies
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.
9pointsThe wrapper documentation names a result flag and a data field; the programmer confirms the display currently checks only whether the returned object is nonempty.
18pointsThere it is. Have the programmer check that flag before using the data. A full envelope can contain bad news just as easily as good news.
16pointsWhat's left on the screen after an error? Ours once kept a lovely green value from the last successful read. Very reassuring. Completely out of date.
8pointsI'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.
20pointsIt retains the old value with no age shown; I have added that to the fault description rather than treating the flag check as the whole repair.
13pointsGood 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.
6pointsTest a good result followed by an error, not just an error on startup; that's how the old value gets stranded on the screen.
10pointsBoth environments remain in use for now, and the developer is adding a small adapter for each documented format plus that good-then-error test.
23pointsWhat 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.
21pointsAnd show a plain message for whoever uses it. Unknown response is enough on the main display; the developer can have the ugly details in the log.
22pointsUnknown responses now show unavailable, and the stored last-good value is labelled with its age; the offline examples pass for both documented formats.
11pointsThe workshop check remains outstanding. At least we now have a failed response that fails visibly, an unexpectedly useful improvement for a status display.
19pointsLet 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.
4pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .