Repository navigation
test(id): log_sync bulk-session test is load-sensitive — 60s retry deadline flakes under parallel load #4057
Description
Found while landing #4015/#4047 (2026-11-01): log_sync::tests::test_a_bulk_session_moves_every_event_across_pages failed once in a full cargo test -p id --lib run on the laptop while the box was under heavy parallel load (load avg ~30–43: a nix sandbox build plus fleet builds):
retrying the bulk session after a transport error: the sync session did not finish within 60s
assertion left == right failed: left 0, right 210 (accepted tally)
test result: 1521 passed; 1 failed
Re-run in isolation immediately after: ok in 39.36s — the test itself takes ~39s of wall time unloaded, so its internal 60s retry deadline has little headroom when the machine is saturated. Not a logic failure: zero events were accepted because the retried session never got scheduled time, not because sync misbehaved.
Context: the same suite at the same code was fully green (1514 passed) earlier the same day at lower load. This is a robustness/headroom issue in the test (deadline vs. work size), worth a look by the log_sync owner — e.g. scale the deadline, or reduce the per-test event volume. priority/low: it only bites on loaded shared machines, but it did block a verification cycle for the #3720 fold.
Acceptance criteria
log_sync::tests::test_a_bulk_session_moves_every_event_across_pagespasses reliably under parallel load comparable to the flake (deadline scaled to work size, or per-test event volume reduced, with the rationale recorded on this issue).- The full
cargo test -p id --libsuite is green on a loaded shared machine, not only in isolation. - Test-only change unless the log_sync owner records a reason for a production change.
Activity
dezren39 commentedon Nov 2, 2026
Intake review
dezren39 commentedon Nov 2, 2026
Same family, bigger cluster (2026-11-01 evening): a full host
cargo test -p idrun for the #4111 verification failed 9cli_integrationtests at once (8serve_tests::*startup-deadline expiries + 1 put_get) while a second fleet lane's suite (~/git/fleet/4838) was running its ownid servetest processes on the same host — fixed loopback ports (e.g. 127.0.0.1:8081) and 30s/5s startup deadlines collide across concurrent suites, and panic paths leakid servechildren that keep ports bound. Sampled failures all pass solo (test_world_state_survives_a_serve_restart: ok in 182.94s once the box was clear of leaked servers). Not a code regression; the nix checkPhase (isolated loopback) is unaffected. Leaving this issue as the tracker for the class.dezren39 commentedon Nov 2, 2026
Correction to my earlier comment on this issue: the claim that
test_world_state_survives_a_serve_restartpassed solo in 182.94s rested on a misattributed tool delivery (this environment's known output-scrambling failure mode). The run's true terminal state, confirmed from the session record afterward, was a 600s timeout kill (rc=124) under peak load — so that specific solo pass is UNVERified and should be disregarded. What is verified by directly-read logs: in the fold switch's in-sandbox checkPhase, the serve tests in the run set passed (attempt 2's only failure was the unrelated test_put_with_custom_name, root-caused as #4152 and fixed), and attempts 3–4 built fully green. The contention mechanism itself (a fleet lane's concurrent suite in ~/git/fleet/4838 with liveid serveprocesses, observed directly) stands; the per-test solo-pass evidence does not.test(id): scale the bulk page-transfer session deadline to its work (#…
dezren39 commentedon Nov 3, 2026
🤖 Agent note · triage-verified + PR opened
SyncProtocol::acceptuses productionSESSION_DEADLINE, and the test's responder handler (Capture) hardcoded the moduleDEADLINE, so both sides were pinned to 60 s under load. Both must move together.BULK_DEADLINE= 3x production (180 s), ~4.6x headroom over the unloaded runtime, and a genuine hang still fails in minutes.Capturegained adeadlinefield with aresponder_with_deadlinehelper; every other log_sync test keepsDEADLINE/production. Test-only change, no production code touched.id servechildren) and is not addressed here — it stays tracked on this issue as the class tracker if Drew wants a separate fix packet.developing-today commentedon Nov 3, 2026
agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 30 (priority/low). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03
dezren39 commentedon Nov 4, 2026
agent-note:v1
state: done — triaged, CONFIRMED, fix already in flight (task 8741, repo-worker-code lane code-l, 2026-11-04T04:11Z)
Fresh triage at current main: