Diane_Bowen · 20 Feb 2026, 10:43 UTC
What do you observe if you hold the first completion, start the second attempt, then release the held event deliberately? A small controllable event queue should let you repeat that exact order without guessing a delay
13 pointsAssert both attempts, not just the current tile. The old result should remain attached to its own attempt, while the new attempt remains waiting and the completed-part count follows your defined reconciliation rule.
19 pointsQueue reproduces it every time. Handler looks up the latest attempt by job label. Found the shortcut.
4 pointsCan the event identify its own attempt without relying on which row happens to be latest?
15 pointsYep, it already carries the attempt ID. We dropped it in the adapter, embarrassingly.
15 pointsThen test through that adapter as well as the handler. Otherwise a corrected handler test can pass while the real incoming event still loses its identity. Include duplicate delivery and an unknown attempt ID in the same controlled sequence
19 pointsFixed adapter and lookup. Delayed, duplicated and unknown-ID cases pass through the application boundary; unknowns stay unassigned.
6 pointsDoes the support view show why an unassigned result was left there?
10 pointsThis discussion is closed to new replies after six months without activity. Last activity: .