BrunoBarnes0539 · 31 Jan 2026, 12:36 UTC
Put a controllable queue at the event boundary. Start an attempt, retain its completion, abandon it, start another, then deliver the retained event explicitly. No sleeping required.
25 pointsThat reproduces it every run. The old event carries its original attempt identifier, but our handler only checks which coupon is active. Where would you reject it?
7 pointsAt the state update, before anything becomes complete. The coupon can legitimately recur; the particular attempt cannot borrow another attempt's result.
11 pointsGive your duplicate test something to count as well. We had a display stay correctly green while the same completion added two entries to the downstream list. Looked perfect until somebody counted the rows.
-1 pointsBruno, did the attempt check fix it, or is another path still updating the result?
24 pointsFixed in our offline handler. Old completion leaves the newer attempt waiting; its own completion finishes it. Duplicating either event adds no extra result. Mei's row-count check caught our second insertion path too.
13 pointsGood catch on that second path. I'd leave both checks in, display state and result count. Someone will tidy the code later and wonder why the apparently redundant one exists.
23 pointsThis discussion is closed to new replies after six months without activity. Last activity: .