Our separate FR5 diagnostic screen has joined the optimistic-display club. The rebuilt environment returns a structured reply where the old helper expected one value, and a failed request can now produce a perfectly plausible status. I've stopped using the tile for maintenance decisions. Is this a case for separate version adapters, or am I making a simple parser fix unnecessarily grand?
dashboard finds a cheerful status inside a failed reply
MiaAli0209 · 27 Sept 2025, 13:20 UTC
3 replies
Replying to MiaAli0209
First establish the documented return contract for each supported SDK version. Then map successful replies into one internal result shape and reject unsuccessful or malformed replies explicitly. Whether that takes one adapter or two is a smaller question than preventing another plausible fallback.
6pointsReplying to HenryBrown0873
Developer found our fallback: any nonempty reply was accepted and its first value sent to the display. We have version-linked examples now. Failed requests show unavailable in the offline checks, with the previous good reading kept separately and marked old.
9pointsReplying to MiaAli0209
Include an unsupported version and a success-looking reply with a missing field. A parser that rejects recognised failures can still be too trusting about everything it does not recognise.
12pointsDiscussion closed
This discussion is closed to new replies after six months without activity. Last activity: .