Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Windows: the suite's failure count tracks machine load, not the tree (216 of 227 failures are 5s timeouts on a green commit)

Aperta
  • Qualcosa non va?
#1,773 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
node.js, typescript
Ambito
performance, testing-qa

Direzione di ricerca

Start with __tests__/wal-heal.test.ts:165 and the Vitest configuration for testTimeout, hookTimeout, and maxWorkers; compare the Windows runs and JSON reports described in the issue. Check how the WAL heal is started and whether the test can observe its completion, then investigate the separate worker-exit report. Done means the suite's results and exit code are reliable under load, without masking real failures.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

On Windows, the suite's result depends on how loaded the machine is, not on the tree. Three full runs of the same commit (cd4e65b) on the same box produced 0, 3 and 227 failures. The 227-failure run contains no product defect I can find — 216 of the 227 are Test timed out in 5000ms.

The three runs

Run passed failed failed suites exit
A (idle box) 4396 0 0 1
B 4393 3 6 1
C (loaded) 4035 227 144 1

Failure breakdown for run C, from its --reporter=json report:

216  Error: Test timed out in 5000ms.
  5  Error: Timed out after 10000ms
  2  Error: Timed out waiting for response init
  1  Error: Timed out after 12000ms
  1  Error: Hook timed out in 10000ms.
  1  Error: EPERM, Permission denied: ...\Temp\codegraph-visibility-3DiTWG
  1  AssertionError: expected 79425392 to be less than or equal to 67108864

225 of 227 are timeouts. Its stderr additionally holds 119 EPERM temp-directory teardown errors and one Error: Worker exited unexpectedly (tinypool).

Environment: Windows 11 Pro, 32 logical cores, 128 GB RAM, Node (not Bun), vitest run --maxWorkers=8.

Two specific things

1. __tests__/wal-heal.test.ts:165 fails on a wall-clock deadline, not on the behaviour it tests.

const deadline = Date.now() + 30_000;
while (walSize() > WAL_HEAL_THRESHOLD_BYTES && Date.now() < deadline) {
  await new Promise((r) => setTimeout(r, 200));
}
expect(walSize()).toBeLessThanOrEqual(WAL_HEAL_THRESHOLD_BYTES);

open() kicks the heal off in the background and the test polls for 30s. Under load the heal does not finish inside that window, and the assertion then reports a size (79,425,392 against the 64 MiB threshold) that reads like a real regression — the same byte count in two separate runs, which is exactly what makes it look deterministic rather than flaky. It is a timeout wearing an assertion's clothes. Waiting on a signal from the heal itself, rather than a wall clock, would make it honest on a slow box.

2. A fully green run still exits non-zero.

Run A is the interesting one: success: true, 0 failed tests, 0 failed suites, 4396 passed — and vitest exits 1, because a pool worker died after the last test finished. Any CI or automation that trusts the exit code over the JSON report treats a completely clean suite as a failure. I hit this in my own tooling; flagging it because the report and the exit code disagreeing is worth knowing about independently of the timeouts.

Suggestion

The 5s default testTimeout is the dominant factor — it is what turns a busy Windows box into 216 failures. Raising testTimeout (and hookTimeout) on win32, or lowering the default maxWorkers there, would make the suite report the tree instead of the load. The EPERM teardown class is separate, and #1717 covers it.

Happy to attach the three full JSON reports if useful.

Lingua principale
C
Stelle
73.2k
Fork
4.7k
Merge medio
2h 13m
PR unite (30g)
418

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di colbymchenry/codegraph

Tutte le issue di colbymchenry/codegraph

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.