Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Temp dataRootDir leaked on abnormal exit or startup failure

Đang mở
  • Có gì không ổn?
#37 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
58/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
testing-qa

Hướng nghiên cứu

Start in src/harperLifecycle.ts by reading teardownHarper(), trackHarperProcess, signalHarperTree(), and startHarper(). Trace how dataRootDir and the log dir are created and how exit, SIGINT, SIGTERM, timeout, and startup paths are handled. Done means catchable abnormal exits clean temporary directories and startup removes stale harper-integration-test-* trees without affecting live runs.

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

Mô tả

teardownHarper() removes the run's temp dataRootDir, but only when it is actually reached — which is solely via each suite's own after/afterEach hook. On a failed, killed, or timed-out run the directory is left behind forever.

Mechanism (current main)

  • src/harperLifecycle.ts — teardownHarper() does rm(dataRootDir, { recursive: true, force: true, maxRetries: 10 }). This is the only place the data root is removed.
  • The interrupt-safety net, trackHarperProcess (registered on exit / SIGINT / SIGTERM), calls signalHarperTree() to kill processes. It never touches dataRootDir.
  • On SIGKILL, nothing runs at all.

So the cleanup path and the interrupt path are disjoint: every abnormal exit leaks a temp tree.

Observed impact

On a dev box this accumulated ~160 orphaned /tmp/harper-integration-test-* directories with no owning process, driving /tmp down to 3.1 G free, at which point runs failed with Disk quota exceeded.

Secondary consequence worth recording because it cost real time: on a machine where /tmp is a RAM-backed tmpfs, once it fills, every Bash call starts failing with a bare Exit code 1 while file tools keep working. Three separate agent sessions each burned their whole budget misdiagnosing that as something else. The disk symptom does not look like a disk symptom.

Relationship to the existing issues

This is a sibling of, but distinct from, the process/address leaks already tracked:

  • #13 — loopback pool leaks addresses from runners killed mid-shard (dead-PID sweep only runs when the pool is full)
  • #29 — detached Harper children orphaned permanently on SIGKILL/SIGHUP; reap guard covers only exit/SIGINT/SIGTERM

Those two are about processes and bound ports, and they are genuinely hard (SIGKILL is uncatchable from the parent, hence #29's child-side parent-liveness watchdog proposal). This one is about filesystem state, is not covered by either, and is untouched by the recent SIGINT/SIGTERM hardening commits.

Suggested direction

Wire dataRootDir (and the log dir) removal into the same trackHarperProcess reaper that already handles the catchable signals, so a Ctrl-C or a timeout cleans up. For the SIGKILL case the parent can do nothing, so the practical complement is a stale-directory sweep at startup: on startHarper, remove harper-integration-test-* trees whose owning PID is gone — the same liveness test #13 already applies to pool addresses.

Found by the qa-explorer campaign.

— Claude Opus 5.5

Ngôn ngữ chính
TypeScript
Star
1
Fork
0
Không có pull request nào được merge trong 30 ngày

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

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 HarperFast/integration-testing

Tất cả issue của HarperFast/integration-testing

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.