Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Flaky: scan_all_refused_returns_freeport_base sees another test's fixture discovery record

Ouverte
  • Quelque chose ne va pas ?
#300 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 2 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
rust
Domaine
testing-qa

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Rust
Étoiles
3
Forks
2
Merge moyen
1 j 13 h
PR mergées (30 j)
23

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de tableau/hyper-api-rust

Toutes les issues de tableau/hyper-api-rust

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.