SamAli0246 · 14 Feb 2026, 03:35 UTC
Can your test retain the first completion in a queue, start the second attempt, then release that saved event when you choose? That would remove the timing lottery.
20 pointsDeveloper can control that boundary. We are using the retained messages with their actual attempt references.
14 pointsI'd also send the new completion twice. Otherwise you fix yesterday's message and still get two rows from today's one. The screen can look perfectly sensible while the report is a mess.
13 pointsGive the test an expected accepted-item total and expected attempt history as well, so it checks what the next person reads rather than only whether a handler returned normally.
-7 pointsExplicit queue reproduces the bug every time. Old completion closes the new attempt because matching uses the sample only.
8 pointsSo the sample identity is being asked to identify an attempt too. Can the state update require the current attempt reference before it marks anything complete?
4 pointsCorrected there. Old completion no longer closes the new attempt. Current duplicate adds no second result row.
23 pointsDecent. Keep those exact event orders in the regression set, including the downstream count Toby mentioned. Much easier to explain than 'try it until the bad thing happens'.
14 pointsThis discussion is closed to new replies after six months without activity. Last activity: .