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

Flaky: scan_all_refused_returns_freeport_base sees another test's fixture discovery record

Đang mở
  • Có gì không ổn?
#300 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ó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
72/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ệ
rust
Lĩnh vực
testing-qa

Hướng nghiên cứu

Start in hyperdb-mcp/tests/daemon_tests.rs at scan_all_refused_returns_freeport_base and inspect nearby tests using discover(), write_discovery_file, scan_for_daemon, or resolve_port_scan. Run the daemon test binary to reproduce the contamination, then audit those tests for isolated HYPERDB_STATE_DIR values and consistent ENV_LOCK use. Done means the suite no longer observes another test's discovery record.

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

Mô tả

Symptom

scan_all_refused_returns_freeport_base failed on test (ubuntu-latest) at hyperdb-mcp/tests/daemon_tests.rs:1329:

expected FreePort(base), got Found(DaemonInfo { pid: 12345,
  hyperd_endpoint: "127.0.0.1:54321", health_port: 36131,
  started_at: "2026-05-20T10:30:00Z", version: "0.1.3" })
test result: FAILED. 62 passed; 1 failed; finished in 18.23s

Run 34076312106, on a PR whose diff is documentation, two benchmark comments, and one test comment — nothing that touches discovery. So this is a pre-existing isolation problem, not a regression.

Diagnosis

The values in that DaemonInfo are the tell. pid: 12345, version: "0.1.3", and hyperd_endpoint: "127.0.0.1:54321" are literal test-fixture constants, not anything a real daemon would report. But health_port: 36131 is an ephemeral port assigned at runtime.

So a different test in the same binary published a fixture discovery record, and this test's scan found it. cargo test runs tests within one binary on parallel threads by default, so two tests sharing a state directory will see each other's records. The scan is behaving correctly; it is being handed contaminated state.

Why it is worth fixing rather than re-running

This is the fourth distinct intermittent failure observed in this area today:

  • engine_recovers_after_hyperd_killed — root-caused and fixed in #286 (a readiness gate that returned the pre-kill endpoint).
  • attach_on_missing_create_is_idempotent_for_existing_file — #288, Windows only, needs a Windows runner.
  • persistent_lock_keeps_mcp_available — observed timing out on a 2-second budget for a contended query; passes on re-run.
  • This one.

Individually each looks like noise. Together they make the daemon suite unreliable enough that a red leg no longer carries information, which is the real cost — it trains everyone to re-run rather than investigate, and a genuine regression then hides in the noise. #286 is the proof that at least one of these was a real product bug rather than test flakiness.

Fix direction

Give every test that reads or writes discovery state its own HYPERDB_STATE_DIR, so no two can observe each other. Several tests already do this via TempDir, and the pattern is established — this looks like a case that was missed rather than a design gap.

Worth auditing the whole file for the same shape while in there: any test that calls discover(), write_discovery_file, scan_for_daemon, or resolve_port_scan without pinning the state directory. Note some tests deliberately use the process-wide ENV_LOCK; check whether that lock is being acquired consistently, since a test that skips it can race the ones that hold it.

Provenance

Observed on main-based CI at 05e993f. Verified that the PR's own diff cannot influence discovery.

Ngôn ngữ chính
Rust
Star
3
Fork
2
Merge trung bình
23 giờ 11 phút
Pull request đã merge (30 ngày)
65

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 tableau/hyper-api-rust

Tất cả issue của tableau/hyper-api-rust

Issue tương tự

Thêm issue về Rust

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.