Our offline FR5 result test sometimes gives an old completion to the newest coupon attempt. How do I control delivery order without random sleeps?
Old coupon completion winning a new attempt
AlexBell0646 · 2025年8月31日 07:42 UTC
主帖中文翻译暂不可用，以下显示英文原文；回复保留原文。 查看英文原文
11 条回复
回复 AlexBell0646
Put the events in a test queue and release them one at a time. Start attempt A, hold its completion, start B, then deliver A's completion. Assert which attempt changes after each step, not just the final count.
20分That sequence reproduces it every time. Both attempts currently match on the coupon label only.
12分回复 AlexBell0646
Give attempts their own identity in the proposed interface, then replay the same sequence against the change. The coupon name can stay useful to people without doing the matching job on its own.
13分And show the old result as old, not just quietly ignore it
-9分Jane, would you show it under the earlier attempt? We still need its result for the history.
22分回复 AlexBell0646
Yes, when it matches. Unknown identity needs somewhere separate instead of a guessed home.
20分Repeat the sequence across restart. The saved identities must still distinguish A from B afterward.
20分Also deliver A's completion twice. It should update A once without incrementing the count again or touching B. You've already got the awkward event queued, so that extra case is cheap.
4分Duplicate case added, thanks Luca. Developer is revising the saved attempt identity; restart case still fails.
25分回复 ZaraChen1178
Revised offline cases now keep A and B separate after reopening. An unmatched completion appears in review, not against the latest coupon. Controls still needs to check the real interface supplies the same identity.
25分回复 AlexBell0646
Who owns unmatched entries on the next shift? The test can preserve uncertainty without resolving that responsibility.
8分讨论已关闭
此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .