[Web] Flaky test: InvoiceWorkspace "holds a header Issue click…" intermittently fails on invoice-issue-saving-hint

[bdunncompany]

Summary

InvoiceWorkspace.test.tsx › "holds a header Issue click while the editor is dirty, then fires it when the save settles" fails intermittently in the web suite, with:

TestingLibraryElementError: Unable to find an element by: [data-testid="invoice-issue-saving-hint"]

It is one failing test out of 534 files, so it reddens the whole Test Web job and the CI Success aggregate gate with it.

Two confirmed occurrences, both on unrelated changes

1. main @ 38150ac2f (2026-08-06). The merge that produced that commit was fix(web): stop dynamic device groups blanking the /devices/groups page #3179, which touches zero billing files. Re-running the identical commit with no code change passed, which is what established it as a flake rather than a regression.
2. fix(api): honour the script's own timeoutSeconds in the stale reaper (#3190) #3213 (2026-08-07), an apps/api-only change that touches no web code at all. Same test, same assertion.

Occurrence 2 is the reason this is worth filing: the flake now blocks unrelated pull requests from going green.

Why it is timing-shaped

The assertion targets invoice-issue-saving-hint, which by design only exists while a save is in flight:

fireEvent.change(screen.getByTestId('invoice-notes'), { target: { value: 'Edited' } });
fireEvent.blur(screen.getByTestId('invoice-notes'));
await waitFor(() => expect(screen.getByTestId('invoice-issue-saving-hint')).toBeInTheDocument());

The PATCH is a promise deliberately left unresolved until later in the test, so the save should stay pending for the whole window — which is why the failure is surprising and why I have not guessed at a fix.

What I could not establish

It does not reproduce locally. 6/6 clean runs of that file on Node 22.23.2 on an idle machine. That is consistent with a load-sensitive race that only surfaces on a busy runner, but I could not prove the mechanism, so I have deliberately not sent a speculative patch to the save/hint state machine — whoever owns that flow will know in a minute what took me an hour of guessing.

Two plausible directions for whoever picks it up, neither verified:

• the blur-triggered save has not been dispatched yet when waitFor gives up, so the hint has genuinely not rendered (a debounce or effect-ordering window);
• the hint's visibility depends on a second piece of state that has already settled by the time the assertion runs.

Happy to build the fix if you can point at which of those it is, or if you would rather I dig in properly.

[ToddHebebrand]

Confirmed, and there's a prior instance that makes this more actionable than a second sighting would normally be.

This is the same flake as #2925, filed 2026-07-29 against the same file and the same invoice-issue-saving-hint assertion — but a different test case: "does NOT fire a queued Issue when the pending save fails — the whole point of the failure nonce" (InvoiceWorkspace.test.tsx:208). That one first surfaced on dependabot PR #2906's Test Web run and was likewise established as a flake by a same-commit rerun passing.

Two sibling test cases in one file failing identically is the finding. It rules out "one badly written assertion" and confirms the cause is the shared pattern both cases are built on: a real, non-fake-timer promise race using manual resolvePatch/rejectPatch handles, asserted through waitFor's default 1000ms/50ms polling. Under CI load the PATCH-in-flight indicator (InvoiceActions.tsx:365) simply hasn't rendered inside the poll window. Anything that fixes only the case named in this issue will leave the other one live, and we'll be back here in another week.

So the fix has to target the pattern, file-wide: either move these cases onto fake timers, or raise the waitFor timeout for every saving-hint assertion in the race pattern — not just the two that have flaked so far. Worth grepping the file for the other assertions sharing the shape before picking, since two of them have now proven they can go over 1000ms.

Consolidating onto this issue — #2925 was mine and had only the single occurrence; this one carries the broader evidence and, more importantly, the fact that it now blocks unrelated pull requests. Closing #2925 as a duplicate and pointing it here. Its root-cause analysis is reproduced above so nothing is lost.

Your point about the blast radius is the part that moves this off "cosmetic": one test of 534 files reddens Test Web and the CI Success aggregate with it, and CI Success is the sole required status check on the main-branch ruleset. So this flake can hold up any merge, which is exactly what it did to #3213 today.

Labeled tech-debt to match #2925.

[bdunncompany]

Taking this one.

You've already set the direction — file-wide, fake timers or a raised waitFor, not a per-test patch — and it's now had three sightings (#2925, this, and #3277 on #3264's CI two days later). Rather than log a fourth, I'll fix it.

@ToddHebebrand if you'd rather keep it, or you've already got something in flight, say so and I'll drop it immediately.