Summary
The test "a package member's resend rehydrates every line of the package" in test/lib/server-attendees/resend-notification.test.ts waits for a fire-and-forget webhook dispatch using await new Promise((resolve) => setTimeout(resolve, 0)). This pattern was relocated verbatim from the original monolithic test file (test/lib/server-attendees.test.ts, original line 2040) during the test-split PR and was intentionally left unchanged to preserve existing test assertions.
Rationale
setTimeout(..., 0) is scheduler-dependent and can race with the actual webhook dispatch, which may cause intermittent/flaky test failures depending on event loop timing.
Suggested change
Replace the zero-delay timer with a deterministic synchronization mechanism, for example:
- Expose an awaitable completion signal (e.g., a promise) from the fire-and-forget webhook dispatch code path used in tests, or
- Use a deferred/resolvable stub for
globalThis.fetch that the test can await directly once the request has actually been dispatched, instead of guessing with a timer.
Affected areas
test/lib/server-attendees/resend-notification.test.ts (test: "a package member's resend rehydrates every line of the package")- Possibly the webhook dispatch helper/implementation invoked by the resend-notification route, if a hook needs to be added for deterministic test synchronization.
Acceptance criteria
- The test no longer relies on
setTimeout(resolve, 0) to wait for the webhook fetch call.
- The webhook call assertion (
expect(webhookFetch.calls.length).toBe(1)) is deterministic and does not depend on event loop timing.
- Existing test assertions about the webhook payload continue to pass unchanged.
References
Summary
The test "a package member's resend rehydrates every line of the package" in
test/lib/server-attendees/resend-notification.test.tswaits for a fire-and-forget webhook dispatch usingawait new Promise((resolve) => setTimeout(resolve, 0)). This pattern was relocated verbatim from the original monolithic test file (test/lib/server-attendees.test.ts, original line 2040) during the test-split PR and was intentionally left unchanged to preserve existing test assertions.Rationale
setTimeout(..., 0)is scheduler-dependent and can race with the actual webhook dispatch, which may cause intermittent/flaky test failures depending on event loop timing.Suggested change
Replace the zero-delay timer with a deterministic synchronization mechanism, for example:
globalThis.fetchthat the test can await directly once the request has actually been dispatched, instead of guessing with a timer.Affected areas
test/lib/server-attendees/resend-notification.test.ts(test: "a package member's resend rehydrates every line of the package")Acceptance criteria
setTimeout(resolve, 0)to wait for the webhook fetch call.expect(webhookFetch.calls.length).toBe(1)) is deterministic and does not depend on event loop timing.References