We have real attempt references now. Random delays still miss the bad ordering. I need explicit event release.
Our FR5 delayed-result test still depends on sleeping long enough
SamAli0246 · 2026年2月14日 03:35 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
8 条回复
回复 SamAli0246
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分Developer can control that boundary. We are using the retained messages with their actual attempt references.
14分回复 SamAli0246
I'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分回复 BenBrown0892
Give 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分Explicit queue reproduces the bug every time. Old completion closes the new attempt because matching uses the sample only.
8分回复 SamAli0246
So 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分Corrected there. Old completion no longer closes the new attempt. Current duplicate adds no second result row.
23分回复 SamAli0246
Decent. 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分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .