Failed FR5 reply displayed as a valid status

SamCarter1029 · 17 Nov 2025, 20:33 UTC

Closed
SA
SamCarter1029
Our replacement SDK returns a container; the old FR5 dashboard wrapper reads part of it as status even on failure.

17 replies

LE
LeoChen1145
Replying to SamCarter1029

Check the documented return shape for the exact SDK version before indexing it. Save one successful and one failed response with their versions so the wrapper change has something concrete to be tested against.

7 points
KA
KaiBrooks0802
Replying to SamCarter1029

Establish whether that interpreted status is used only for display or also by another part of the application, because the same parsing error may have more than one visible effect.

13 points
SA
SamCarter1029
Replying to KaiBrooks0802

Display only, Kai. The wrapper takes the first value without checking request success.

20 points
LU
LucaAllen0265
Replying to SamCarter1029

Sam, do you still need to support both SDK versions? That changes whether one replacement parser is enough or the maintainer needs two explicit input formats behind the same display.

-3 points
JA
JasperCarter0986
Replying to LucaAllen0265

Luca, I would want the supported-version list in the handover either way. We have bought software updates before discovering nobody agreed how long the older setup would remain supported.

20 points
SA
SamCarter1029
Replying to LucaAllen0265

Both versions for now, Luca. Different teaching laptops. Maintainer has examples from each.

13 points
LE
LeoChen1145
Replying to SamCarter1029

Use version-specific interpretation behind one clear display result. Unsupported shapes should fail visibly, not be guessed into whichever old format is easiest to accept.

16 points
LU
LucaAllen0265
Replying to JasperCarter0986

Jasper, thanks, that is the ownership question I was circling. Sam, who updates the examples and parser when another SDK version is introduced?

21 points
SA
SamCarter1029
Replying to LucaAllen0265

Course software maintainer. Added supported versions and the update check to the handover draft.

14 points
KA
KaiBrooks0802
Replying to SamCarter1029

Include a failed request following a successful reading, so the screen does not leave the old value looking current when the new parser correctly reports failure.

16 points
LE
LeoChen1145
Replying to KaiBrooks0802

And failure before the first successful read. No historical value exists in that case, even if the widget arrives with a cheerful default.

25 points
SA
SamCarter1029
Replying to LeoChen1145

Both cases added. Failed current read shows unavailable; previous reading stays separately marked last known.

18 points
JA
JasperCarter0986
Replying to SamCarter1029

Does the previous reading retain its time and source laptop or connection identity? That would help someone using two setups avoid treating the last good display as belonging to the current session.

4 points
LU
LucaAllen0265
Replying to SamCarter1029

Also have a student read those states, Sam. Ask what is known now, not whether the revised screen looks nice.

9 points
SA
SamCarter1029
Replying to JasperCarter0986

Time and connection identity retained, Jasper. Student walkthrough scheduled; malformed replies still need coverage.

15 points
LE
LeoChen1145
Replying to SamCarter1029

Include missing required data and wrong field types in those malformed cases. A response can say success and still lack the information the display requires.

7 points
LU
LucaAllen0265
Replying to SamCarter1029

Did the walkthrough distinguish unavailable now from that last-known reading? Interested whether the words carry the difference without an explanation from the maintainer.

19 points

Discussion closed

This discussion is closed to new replies after six months without activity. Last activity: .