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

🤖 tests: backgroundProcessesRepro reads exit_code before the trap writes it (CI flake)

オープン 初心者向け
  • 何か問題がありますか？
#6,504 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

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

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

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
72/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
shell, typescript
領域
testing

調査の方向性

src/node/services/backgroundProcessesRepro.test.ts の 107 行目付近にある spawnExited ヘルパーから始めてください。このヘルパーは終了コードのファイルを待ち、その後一度だけ読み込みます。マーカーを書き込む EXIT トラップは src/node/runtime/backgroundCommands.ts の 83 行目付近にあります。同じテストファイルの 386 行目と 478 行目付近にある、同様の待機してから読み込む処理も確認してください。ファイルに数値が含まれるまでヘルパーが解決せず、負荷の下でもテストが繰り返し成功すれば完了です。

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

説明

Problem

backgroundProcessesRepro.test.ts failed once in CI and passed on the rerun. The failing test is "terminating a background process that already exited > a stop after a natural exit sends no signal to the process group" (2013 ms).

  • Run: https://github.com/coder/xum/actions/runs/38532297270 (attempt 1, job "Test / Unit (1/6)", PR #6475). Attempt 2 passed.
  • expectReproFailure reported "repro failed elsewhere". The real error came from the setup helper spawnExited, not from the target assertion:
at spawnExited (src/node/services/backgroundProcessesRepro.test.ts:108:63)
expect(received).toBe(expected)
Expected: "3"
Received: ""

Cause (from reading the code, not reproduced yet)

  1. The wrapper's EXIT trap writes the marker with echo $? > "$__MUX_EXIT_CODE_PATH" (src/node/runtime/backgroundCommands.ts:83). The shell creates the file first and writes the digits after that. For a short time the file exists and is empty.
  2. spawnExited waits only until the file exists (backgroundProcessesRepro.test.ts:107), then reads it once (line 108). A read in that gap returns "".
  3. The product reader already treats an empty marker as "no exit code yet" (getExitCodeStrict, src/node/services/backgroundProcessExecutor.ts:654-659). So I think only the test helper is wrong. I did not verify every other reader.

This is not the same cause as #6443 (that one is slow happy-dom matcher output inside waitFor).

Possible fix

Make the helper wait until the file holds a number (for example waitFor(async () => /^\d+$/.test((await fs.readFile(f, "utf-8").catch(() => "")).trim()))), and check other tests that use the same "exists, then read" shape on exit_code (lines 386 and 478 of the same file wait on files too).

Generated with xum • Model: anthropic:claude-opus-5-5 • Thinking: high • Cost: $1.26

主要言語
TypeScript
スター
2.1k
フォーク
140
平均マージ
4時間 55分
マージ済み PR（30日）
900

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

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

coder/xum のほかの issue

coder/xum の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

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

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