Back the coverage accumulator off on large apps

[NullVoxPopuli]

Note

Made with Claude Code. Apologies if I've misjudged the tradeoff here — the duty-cycle factor is a number I picked from measurements on one app, so push back if you'd rather it were shaped differently.

The problem

The proactive accumulator (the safety net for Chrome being SIGTERMed before the final take lands) re-takes coverage on a fixed 100ms timer. That assumes takePreciseCoverage is cheap. It isn't — V8 serialises every currently-loaded script, so the cost scales with the app.

I instrumented the call on a mid-size Ember app, running only a handful of unit tests:

calls=24  mean=35.2ms  median=2ms  p90=98ms  max=188ms
calls >50ms: 7 (29%)

p90 is essentially the whole interval. The browser spends most of its time producing coverage rather than running tests, and testem runs N browsers per machine.

On a large suite (~32 browsers per CI machine) this was enough to push 141 tests past their 10s QUnit timeout — tests that pass with coverage off. Both the acceptance and non-acceptance shards went red purely from the overhead, with no coverage errors at all.

The change

Schedule the next take off how long the last one actually took, at roughly a 1/10 duty cycle, and never sooner than a configured floor:

Math.max(cacheInterval, lastTakeMs * 9)

• Cheap takes (small apps, idle periods) keep the current ~100ms cadence — the median measured above is 2ms, so nothing changes there.
• Expensive takes back off proportionally, so the accumulator costs about a tenth of the browser's time no matter how big the app gets.

Self-tuning rather than a knob felt right here: the cost depends on the app under test, so every consumer would otherwise have to hit this and discover the reason before knowing what to set. chrome.cacheInterval (default 100) is exposed for the floor anyway.

The accumulator's purpose is unaffected — it's a fallback for the shutdown race, and a few hundred ms of staleness is well inside what the /_coverage handler's live take covers.

Testing

Full suite passes locally: 5 files / 41 tests, oxlint + oxfmt clean.

What I have not done is prove the 141 timeouts go away, because that needs this released and consumed by the app in question. I can confirm it once it's out — happy to hold the release until then if you'd rather see that evidence first.

Unsure about

• The factor of 9. It gives a ~10% duty cycle, which felt like a defensible default, but it is one number from one app. A different shape (cap the absolute delay, or scale by script count) might suit you better.
• Whether the accumulator should be this eager at all. It only matters in the window where Chrome dies before the final take returns. A much lazier default might lose nothing — but that's a bigger behavioural change than I wanted to make unilaterally.

[github-actions]

Coverage reports

Scenario	Artifact
v2-addon-js	coverage-v2-addon-js.zip
vite-app-js	coverage-vite-app-js.zip
vite-app-using-v2-addon-js	coverage-vite-app-using-v2-addon-js.zip

Each artifact is the scenario's coverage/ folder (HTML report, text/JSON summaries, raw V8 snapshot). Unzip and open index.html.

From this CI run for a1e5386.