My delayed result completes the wrong bracket attempt. Same job label, different attempt; sleeps won't reproduce it reliably.
Why does my old completion tick off the new attempt?
Diane_Bowen · 2026年2月20日 10:43 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
8 条回复
回复 Diane_Bowen
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分Assert 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分Queue reproduces it every time. Handler looks up the latest attempt by job label. Found the shortcut.
4分回复 Diane_Bowen
Can the event identify its own attempt without relying on which row happens to be latest?
15分Yep, it already carries the attempt ID. We dropped it in the adapter, embarrassingly.
15分回复 Diane_Bowen
Then 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分Fixed adapter and lookup. Delayed, duplicated and unknown-ID cases pass through the application boundary; unknowns stay unassigned.
6分回复 Diane_Bowen
Does the support view show why an unassigned result was left there?
10分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .