Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#1,773 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
node.js, typescript
Área
performance, testing-qa

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C
Estrellas
73.2k
Forks
4.7k
Merge medio
2 h 13 min
PR fusionados (30 d)
418

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de colbymchenry/codegraph

Todos los issues de colbymchenry/codegraph

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.