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

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#6,504 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
72/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
shell, typescript
Lĩnh vực
testing

Hướng nghiên cứu

Bắt đầu từ helper spawnExited trong src/node/services/backgroundProcessesRepro.test.ts, khoảng dòng 107, nơi nó chờ tệp mã thoát rồi đọc một lần duy nhất. EXIT trap ghi marker nằm trong src/node/runtime/backgroundCommands.ts, gần dòng 83. Cũng kiểm tra các khối chờ-rồi-đọc tương tự gần dòng 386 và 478 trong cùng tệp kiểm thử. Hoàn thành khi helper chỉ resolve sau khi tệp chứa một số và bài kiểm thử vượt qua nhiều lần dưới tải.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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

Ngôn ngữ chính
TypeScript
Star
2.1k
Fork
139
Merge trung bình
3 giờ 35 phút
Pull request đã merge (30 ngày)
950

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của coder/xum

Tất cả issue của coder/xum

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.