简体中文界面。帖子、指南及政策正文保留原文；未对原文作自动翻译。
AlexBell0646 · 2025年12月15日 17:17 UTC
Use explicit test steps or barriers instead of random sleeps: start the newer attempt, confirm that state is reached, then deliver the retained older event. Keep attempt identities in the test data and assert which attempt changes, not only whether a total increments.
20分Both attempts have distinct IDs. The newer one becomes complete when the old event arrives.
25分Assert that the newer attempt stays unchanged. A successful-looking final counter is not enough.
7分Keep repeated delivery of the current event separate from delivery of the older one. Those expose different mistakes, even if both used to appear as an extra finished item.
5分I'd include restoring the saved history before the delayed delivery, because a clean test start can hide what your real tracker already knows about the old attempt
16分Added an explicit release step for the old event. Failure now repeats without waiting for luck.
10分Good. Keep that failing sequence while the implementation changes, then assert both persisted state and the report output. Correctly retaining the attempt record does not automatically prevent a separate display path announcing a new completion.
19分And include a genuinely new result. Don't make ignoring all completions pass the tests.
22分Does the test restore the same identity scope as the installed tracker, including job run if attempt numbers repeat?
11分Yes, job-run plus attempt identity. Report assertions are still incomplete; stored-state assertions now cover the old event.
20分Keep that remaining report work visible in the handover note, Alex, so a passed tracker test isn't read as proof that every screen counts correctly
7分Please return with the repeated-current and report results when they are ready. You now have a repeatable old-event failure, which is useful progress, not yet the whole regression set.
5分此讨论已连续六个月没有活动，现已关闭新回复。 最后活动： .