Context
`test_txn_commit_wal_crash_recovery` (tests/txn_kv_wiring.rs:1025) intermittently fails on BOTH Linux and macOS CI runners with:
- Linux: `connect failed: Resource temporarily unavailable (os error 11)` (EAGAIN)
- macOS: `connect failed: Connection reset by peer (os error 54)`
Confirmed pre-existing (independent of PR #129):
Symptom
Phase-1 server logs clean startup ("AOF enabled", "Listening on 127.0.0.1:PORT", "WAL v3 writer initialized") but the test client's TCP connect to localhost returns EAGAIN/ECONNRESET for the entire 60s deadline.
Hypothesis
CI runner resource pressure after ~10 minutes of the 2814-test parallel suite — ephemeral port depletion, accept-queue saturation, or scheduler contention. The local test passes consistently (0.19s on unloaded Mac).
Investigation needed
- Run with `--test-threads=1` to isolate from concurrent test resource contention.
- Add `SO_REUSEADDR` to the test harness so port reuse isn't blocked by TIME_WAIT.
- Strace the spawned moon process during a failing run to see if accept() is actually being called.
- Consider gating the test behind `#[ignore]` and running it serially in a dedicated CI job (like crash_matrix_per_shard_aof was wired in FIX-W1-3).
References
author: Tin Dang
Context
`test_txn_commit_wal_crash_recovery` (tests/txn_kv_wiring.rs:1025) intermittently fails on BOTH Linux and macOS CI runners with:
Confirmed pre-existing (independent of PR #129):
Symptom
Phase-1 server logs clean startup ("AOF enabled", "Listening on 127.0.0.1:PORT", "WAL v3 writer initialized") but the test client's TCP connect to localhost returns EAGAIN/ECONNRESET for the entire 60s deadline.
Hypothesis
CI runner resource pressure after ~10 minutes of the 2814-test parallel suite — ephemeral port depletion, accept-queue saturation, or scheduler contention. The local test passes consistently (0.19s on unloaded Mac).
Investigation needed
References
author: Tin Dang