Windows-only flake: backfill_stubs_preexisting_tables_on_reopen fails on table-name assertion

[StefanSteiner]

Summary

backfill_stubs_preexisting_tables_on_reopen failed on the test (windows-latest) leg during CI for #267, a PR whose diff touches only hyperdb-mcp/tests/daemon_tests.rs.

hyperdb-mcp\tests\table_catalog_tests.rs:429:5
assertion failed: names.contains(&"alpha".to_string())
test backfill_stubs_preexisting_tables_on_reopen ... FAILED
test result: FAILED. 21 passed; 1 failed

Why this is not #267

• test(mcp): measure daemon idle timeout from before the clock starts #267 modifies one file, daemon_tests.rs, and this failure is in table_catalog_tests.rs.
• Both tests test(mcp): measure daemon idle timeout from before the clock starts #267 modifies passed on that same Windows leg (daemon_idle_timeout_shuts_down_daemon ... ok, daemon_heartbeat_prevents_idle_shutdown ... ok; that binary reported 52 passed; 0 failed).
• The assertion is about table names present after a catalog reopen and has no timing content.

Platform

Windows-only so far. The same test (windows-latest) leg passed on the v1.0.0-rc.2 release commit c9bacf2 (job 101457433522), so this is intermittent rather than a persistent break on that commit.

Please root-cause rather than re-run

Two cautions from recent experience in this area.

The failure record is perishable. Re-running a failed job rewrites the run conclusion, so the evidence of this failure disappears and historical flake counts become a lower bound. This was demonstrated live: an earlier run containing a real failure now reads success after a re-run.

Two "flakes" in this repo recently turned out to be real defects, not timing. slow_health_watchdog_reaps_hyperd_after_child_timeout was caused by validate_hyperd_process identifying the engine with ps -p <pid> -o comm=, which on Linux reads the main thread name — and hyperd renames its main thread to hyperdMain, so the guard rejected the very process it existed to reap (200/200 on Linux). And daemon_idle_timeout_shuts_down_daemon (#267) was a measurement-reference bug, where the test captured its Instant::now() after DaemonState::new() had already started the idle countdown. In both cases the obvious timing explanation was wrong.

So a backfill/reopen assertion failing on one platform is worth reading as a possible ordering or persistence bug in the catalog-reopen path before being written off as flaky.