A Playwright `toPass` block clicks Refresh then asserts the balance, and it times out only in CI. What's wrong?

## What the block actually does on every probe `await expect(async () => { ... }).toPass()` retries the callback **whole**. Playwright has no memory of which statements already succeeded on a previous attempt, so a block written as ```ts await expect(async () => { await page.getByRole('button', { name: 'Refresh' }).click(); const balance = await page.getByTestId('balance').textContent(); expect(balance?.trim()).toBe('$1,250.00'); }).toPass(); ``` is not "click once and keep checking". It is "click, check, and if the check fails, click again". Every probe issues a new refresh. ## Fault one: the action repeats and resets the state On a developer machine the statement usually loads inside the first probe, so the click happens once and the test passes; nobody notices the shape of the code. In CI the machine is slower and the API is further away, so the first check fails, and the loop starts: 1. Probe 1 clicks Refresh; the balance widget goes to its loading state. 2. 100 ms later probe 2 clicks Refresh again, cancelling or superseding the first load. 3. Each subsequent probe repeats this, and the widget is now permanently mid-refresh. The wrapper meant to absorb slowness is now **causing** it. This is the signature of the bug: it worsens with load, it never reproduces locally, and the trace shows a rhythmic stream of identical requests. ## Fault two: nothing bounds the loop `toPass` defaults to `timeout: 0`, which means no deadline of its own and no inheritance of the expect timeout. So the block probes until the **test** timeout — 30 s by default — terminates the test. Two consequences make the diagnosis harder than it should be: - The failure is reported as a test timeout, not as an assertion failure, so the report does not name the condition that was never met. - Any auto-retrying assertion **inside** the block carries its own timeout (5 s by default). One probe can therefore consume five seconds before the outer loop even gets a turn, so a block that looks like it retries dozens of times may manage only a handful of attempts. ## Repairing it 1. **Move the action out.** Click Refresh once, above the block; retry only the observation. 2. **Narrow the check.** If it reduces to one value, `expect.poll` gives a matcher diff on failure instead of an opaque timeout. 3. **Bound the wrapper.** Pass an explicit `timeout` to `toPass` so a stuck condition fails as an assertion, comfortably inside the test timeout. 4. **Shorten inner timeouts.** Give any nested auto-retrying assertion a short `{ timeout }` so one probe cannot eat the whole budget. ## When the action does belong inside Occasionally re-acting is genuinely the point — a link that is briefly inert, or a control that only becomes live once a background job registers it. Keep those blocks honest: - Make sure the action is **idempotent** and cheap enough to fire ten times. - Widen the `intervals` so the repeat rate matches what the system can absorb. - Never put a state-changing action — submitting a transfer, confirming an export — inside a retried block; a retry then means doing it twice. - Prefer the smallest block that expresses the condition, so the failure still tells you something. ## The lesson to carry out of it A retry wrapper is only safe when the thing it repeats is a **read**. The moment a block mixes acting with asserting, its retry semantics stop being a safety net and become part of the system under test — and a wrapper without an explicit timeout guarantees that when it does go wrong, the report tells you the least useful thing it could have said.