Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Flaky: scan_all_refused_returns_freeport_base sees another test's fixture discovery record

Offen
  • Stimmt etwas nicht?
#300 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
72/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
testing-qa

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Rust
Sterne
3
Forks
2
Ø Merge
1 T. 7 Std.
Gemergte PRs (30 T.)
20

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus tableau/hyper-api-rust

Alle Issues in tableau/hyper-api-rust

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.