fix(harness): bound the no-loss excusal by run size, not connection count

[wshallwshall]

test_load_runner.py::test_run_load_end_to_end_no_loss intermittently reds the required test (windows-2025, py3.14) leg, which blocks auto-merge on unrelated PRs (it held #14). It reproduces identically on main.

The bug is the model, not the number

The reconcile excuses an unconfirmed send — in flight at a connection close, no ACK seen — because sent is counted at write-buffer time, so the frame may never have left the socket. That excusal is capped, correctly, so timeouts == sent can't degrade the intake bound to read >= 0 and let a total ACK-path regression pass as zero-loss.

The cap modelled legitimate stranding as "~one in-flight frame per connection". That does not hold for this sender: _inflight is an unbounded deque, and an open-loop phase paces sends by the offered rate rather than by an ACK slot. What is genuinely in flight at teardown is therefore ~rate × ACK-latency — a share of the run, unrelated to the connection count.

The observed failure is a demonstrably zero-loss run:

sent	90
stranded at teardown	14 (~16%) — against a budget of 4
engine_read	84 = 90 − 6 that never left the socket
engine_written / sink_received	168 / 168 (fan-out 2)
backlog	0

Nothing was lost. The neighbouring acked >= sent // 4 assertion in the test was already deliberately loosened for exactly this teardown behaviour; no_loss's own budget never got the same treatment. That asymmetry is the defect.

The fix

Cap at max(connections, half the run), in all three copies of the accounting (load/report.py, connscale, estate — kept in step deliberately). read >= sent // 2 stays always required, so a dead ACK path still fails loudly while teardown weather does not. It is ~3× the worst stranding observed, and far from vacuous.

Reviewer note — one verdict is deliberately flipped

test_connscale_reconcile_timeout_flood_fails_even_without_shortfall asserted that 6 of 36 unconfirmed is a systemic fault. Under the new bound that is ordinary teardown stranding, so the test would have passed for the wrong reason. It is re-scenario'd to a genuine flood (30 of 36), and a new test pins that the 6-of-36 shape now reconciles clean — the behaviour change, made explicit rather than left implicit.

Two further tests pin that the widened bound has not blunted detection: the excusal stops at exactly half the run (one over flips to a systemic fault with nothing excused), and loss beyond a large excusal still fails.

Verification

• tests/test_harness_reconcile.py: 17 passed. tests/test_load_runner.py: 5 passed.
• Full reconcile-adjacent sweep (43 files: load, connscale, estate, multishard, harness): 668 passed, 3 skipped.
• ruff format/check clean. CI's mypy covers messagefoundry/messagefoundry_webconsole, not harness/.
• Mutation-verified: restoring the old budget = unconfirmed_budget fails all three new tests.

What this trades away, stated plainly

A widened excusal is a weaker intake gate: an engine dropping frames at intake produces no ACK, so those sends count as unconfirmed and are excused. Previously anything past ~1/connection failed; now up to half the run can be excused. The half-cap is what keeps that bounded, and the delivery-side checks (sink_received >= written, backlog == 0) are untouched. The alternative — making the sender wait out its in-flight window so timeouts stays ~0 and the strict bound holds — is the better long-term fix but cannot be validated locally, since the flake only appears under windows-2025 contention.

🤖 Generated with Claude Code