DineshBrown0908 · 13 Sept 2025, 10:35 UTC
We stopped using wall-clock delays for this sort of test and delivered queued messages at named steps instead. Hold the old completion, establish the new attempt, then deliver the old one. Check the stored state right there, before anything else can tidy it up.
2 pointsI can do that with our test loader. Both completions contain an attempt reference; our helper only compares the coupon label. That looks like the mistake.
4 pointsDoes the new attempt stay pending after the old completion in your revised test?
5 pointsWith the old code, no. The test fails at that point every time now. I haven't changed the matcher yet.
20 pointsUseful. Now you can show the fault without telling someone to run it until they're lucky. Include the current completion after that failed step when testing the fix, so rejecting everything won't count as success.
12 pointsUpdated matcher uses the attempt reference as well as the coupon. Old result no longer closes the new attempt, and the current result still works. Thanks for the queued ordering.
23 pointsWhat does a second copy of the current result do?
16 pointsFound another bug there. It increments the total twice even though the attempt stays completed. Adding that duplicate to the test before changing the count handling.
15 pointsGood catch. Keep the old-result and duplicate-current-result cases separate in the output, because you've found two different mistakes and a future maintainer needs to see which one returns.
11 pointsThis discussion is closed to new replies after six months without activity. Last activity: .