Why does our offline inspection screen pass everything?

AaronAllen0262 · 25 Feb 2026, 12:12 UTC

Closed
AA
AaronAllen0262
Our offline stand-in returns true, so the inspection screen stays green even when I give it no coupon result at all; with the UR5e bench unavailable, I want to replace that cheerful nonsense with saved application responses, but I don't know which examples would expose a bad parser instead of merely keeping the demonstration running

16 replies

OL
OliverChen1146
Replying to AaronAllen0262

Have you got a saved failure response as well as a success, because I would start by making the screen tell those apart before collecting a museum of edge cases

22points
AA
AaronAllen0262
Replying to OliverChen1146

Yes, an accepted coupon and a rejected coupon from the same application version; the programmer says the stand-in bypasses the parsing code, which explains a lot

2points
MI
MinaBennett0772
Replying to AaronAllen0262

Then test through the parser. A mock taking a shortcut around the broken bit is just a second application with better manners.

10points
CA
CallumChen1143
Replying to AaronAllen0262

Our packing demo once showed the result of the previous carton, so does your rejected response actually change the displayed coupon identity as well as the colour?

0points
FA
FarahChan1113
Replying to AaronAllen0262

Keep an example with no result too, Aaron, since that was the case that first bothered you.

20points
AA
AaronAllen0262
Replying to MinaBennett0772

The saved reject exposed it: our wrapper tests whether the response has contents, then treats that as acceptance, without reading the result field; the reject response has contents too, obviously

18points
OL
OliverChen1146
Replying to AaronAllen0262

Expensive way to ask whether a box contains paper, that

10points
MI
MinaBennett0772
Replying to AaronAllen0262

What does the corrected code do with an unrecognised result value? Don't let an else branch quietly become another green lamp.

11points
AA
AaronAllen0262
Replying to MinaBennett0772

It reports an unreadable result and leaves acceptance unset; the programmer added a test with an unrecognised value as well as the captured accept and reject, but has not checked the display identity yet

17points
CA
CallumChen1143
Replying to AaronAllen0262

Please do the identity check, Aaron, especially if a coupon result can arrive while another coupon is already selected on screen.

19points
FA
FarahChan1113
Replying to CallumChen1143

Callum, would you include reopening the screen with no new response, so an old colour cannot sneak back in from saved display state?

0points
CA
CallumChen1143
Replying to FarahChan1113

Yes, that is close to what caught us, though ours happened when changing cartons rather than reopening the screen.

0points
AA
AaronAllen0262
Replying to CallumChen1143

We added reject_after_accept, empty_response and reopen_without_result to the application tests, plus a response for the wrong coupon; the first three now pass, but the wrong-coupon case revealed that the heading changes before the old result is removed

8points
MI
MinaBennett0772
Replying to AaronAllen0262

Good find. Does the export have the same old-result problem?

21points
AA
AaronAllen0262
Replying to MinaBennett0772

The export already used the response's coupon identity correctly; we fixed the display reset and the wrong-coupon test now leaves the selected coupon pending, with the other response listed against its own identity, and all five saved-response cases pass through the normal parser and screen code

7points
OL
OliverChen1146
Replying to AaronAllen0262

That's a useful bit of work while the bench is unavailable, and considerably more convincing than true with a cheerful face

3points

Discussion closed

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