[Flaky] InvoiceWorkspace queued-Issue tests fail intermittently in CI (Test Web)

[ToddHebebrand]

Two different tests in apps/web/src/components/billing/InvoiceWorkspace.test.tsx failed on consecutive CI runs of PR #3264 (a PR that touches nothing billing-related), each passing locally (15/15) and on rerun with no code change:

• run 31264337259: holds a header Issue click while the editor is dirty, then fires it when the save settles (1038ms)
• run 31265650231: does NOT fire a queued Issue when the pending save fails — the whole point of the failure nonce

Both are in the queued-Issue/save-settling cluster, and both sit around the ~1s mark, which suggests a fake-timer or waitFor race in the dirty-save → queued-action flow rather than a product bug.

Not chased in #3264 — confirmed unrelated there. Filing so the next Test Web red on these tests has a home.

🤖 Generated with Claude Code

[bdunncompany]

This is the same flake cluster as #3219, which is still open — and #3219 already carries your own file-wide analysis of it.

The lineage, since it's now fragmented across three issues:

• [Web] InvoiceWorkspace failure-nonce test flaky under CI load (waitFor timeout on invoice-issue-saving-hint) #2925 (2026-07-29) — does NOT fire a queued Issue when the pending save fails, first seen on dependabot PR chore(deps): bump jsdom from 29.1.1 to 30.0.1 #2906
• [Web] Flaky test: InvoiceWorkspace "holds a header Issue click…" intermittently fails on invoice-issue-saving-hint #3219 (2026-08-07) — holds a header Issue click…, which you closed [Web] InvoiceWorkspace failure-nonce test flaky under CI load (waitFor timeout on invoice-issue-saving-hint) #2925 onto as a duplicate, noting that two sibling cases in one file failing identically means "the fix must be file-wide (fake timers or raised waitFor)"
• [Flaky] InvoiceWorkspace queued-Issue tests fail intermittently in CI (Test Web) #3277 (this one) — both of those same two tests, on feat(devices): fleet migration posture report (#3244) #3264

So the two runs you caught here are precisely the two cases already consolidated in #3219. Third sighting in ten days, which is a decent argument that it's worth actually fixing rather than logging again.

Worth closing one of the two so there's a single home — I'd suggest keeping #3219 since your file-wide diagnosis is already there and #2925 is already pointed at it, but it's your call and I don't want to close an issue of yours.

I'm happy to take the fix if you want it off your plate: the shape you described (fake timers, or raise the waitFor on the whole dirty-save → queued-action cluster) is well-defined. Say the word and I'll claim it on #3219.

[bdunncompany]

Third occurrence, same cluster — giving it the home you filed this for.

• Run 31434067431, Test Web job 93604086183, on PR fix(api): match process-sample path id against the agent id, not the device id (#3387) #3396
• Test does NOT fire a queued Issue when the pending save fails — the whole point of the failure nonce (the same one from run 31265650231)
• Result Test Files 1 failed | 551 passed (552) — the single failure in the whole web suite
• PR fix(api): match process-sample path id against the agent id, not the device id (#3387) #3396 touches exactly two files, apps/api/src/routes/agents/processSample.ts and its test. Nothing web, nothing billing — same "unrelated PR" shape as feat(devices): fleet migration posture report (#3244) #3264.

One new detail that narrows it. This failure took 5016ms, where the earlier pair sat around ~1s. 5000ms is Testing Library's default waitFor timeout, so this run did not fail on a fast assertion mismatch — the awaited condition never became true at all and the wait ran to exhaustion.

That distinction matters for the diagnosis in the issue. A ~1s failure is consistent with an assertion racing a settle that did happen; a clean 5s timeout says the queued action never fired in that run. Both being the same tests points at the dirty-save → queued-action handoff genuinely not completing under load, rather than the assertion merely sampling too early. A CI runner under contention starving a fake-timer tick or an unflushed microtask queue would produce exactly this pair of shapes from one underlying race.

Not chasing it here — my PR is unrelated and I've re-run the job. Flagging the timing shape because it argues the fix is in the settle path rather than in the test's wait tolerance, and bumping the tolerance would just hide it.

[ToddHebebrand]

Fixed. 46a84cee3 (PR #3284) gave the InvoiceWorkspace queued-Issue tests real waitFor headroom rather than racing the queue drain.

Closing — no recurrence on main since. Reopen if it flakes again in Test Web.