Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

クローズ
  • 何か問題がありますか？
#1,773 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
42/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
node.js, typescript
領域
performance, testing-qa

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
C
スター
73.2k
フォーク
4.7k
平均マージ
12時間 30分
マージ済み PR（30日）
558

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

colbymchenry/codegraph のほかの issue

colbymchenry/codegraph の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。