Flaky: scan_all_refused_returns_freeport_base sees another test's fixture discovery record

Aberta
  • Algo errado?
#300 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
72/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
rust
Domínio
testing-qa

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Rust
Estrelas
3
Forks
2
Merge médio
1d 8h
PRs com merge (30d)
13

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de tableau/hyper-api-rust

Todas as issues de tableau/hyper-api-rust

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.