LeoBaker0449 · 14 Nov 2025, 02:05 UTC
Select the parser from the supported interface version, then check success and required fields before using the status; don't let a nonempty container become your availability decision
12 pointsThat is exactly the current mistake. I have saved a failed reply and a successful one from each documented format, with the version beside them.
4 pointsKeep the unsupported-version case in the test set as well. Otherwise somebody installs another environment later and your explicit two-format parser quietly becomes a guess again.
6 pointsWhat would I actually see when it cannot interpret the answer? We had a display at our workshop that stayed cheerfully green while its little detail line admitted it had no new information. From where I stood, it was green. That was the entire message. I'm not arguing for deleting useful history, but I don't want the old reading doing the job of the current one just because the software has nowhere else to put it.
0 pointsHazel Archer's question is worth testing on the actual screen layout. An unavailable current reading and a dated historical reading can coexist, but they need visibly different roles. Don't rely on one tiny word to explain it.
19 pointsThe current draft blanks the live value and says unavailable. Previous valid reading is in details with its observation time. Nothing historical exists after an initial failure.
9 pointsLeo, include missing fields and unexpected shapes too; a response can look successful enough to tempt the old parser without being valid for either supported format
7 pointsIsabel, exactly. I would rather open details deliberately than squint at green and wonder which bit of the message I'm meant to believe.
22 pointsBoth format parsers pass the success, failure and malformed cases offline. The prior observation time was being refreshed on failure; that is now fixed in the draft too.
17 pointsWhich installed environment does the launcher use? Passing a test in one terminal is not enough if the classroom shortcut starts another package copy.
9 pointsAnd keep those captured examples separate from deliberately malformed cases. The latter are useful tests, not evidence that the controller sent a reply of that shape.
25 pointsLauncher path is recorded and uses the intended environment. Captures and constructed cases are separate. The installed screen check has not been completed yet.
20 pointsCould a person unfamiliar with the rewrite try reading it? The developers already know which bit is old.
6 pointsYes, that is in the operator review. They will see current success, failure after success and initial failure without me explaining each screen first.
5 pointsInclude recovery after a valid reading returns; unavailable should not become a permanent display state either
23 pointsHazel Bell, agreed. The cheap test sequence is useful in both directions. It should also show that returning data carries its own new observation time, not the old one retained for history.
10 pointsScreen review passed those transitions, and the read-only installed check matched the documented format. Unsupported-version deployment remains blocked by the new explicit check. I am keeping the alternate-format tests with the handover.
14 pointsWho owns that test set after handover? The next environment change should trigger it without needing Leo to notice another suspiciously happy tile.
12 pointsThis discussion is closed to new replies after six months without activity. Last activity: .