The reconnect:false case sent its writes straight after ActorOf and gave each
reply a fixed 1 s, so the window also covered the actor's start and first
dispatch. A slow start (cold JIT, starved pool in a full solution run) missed
it. The reconnect:true case was shielded by its 3 s wait for Connected.
The test now waits until the connect attempt the writes race against has been
issued (ConnectAsync entered, held open by the gate), so the actor is provably
mid-attempt and cannot connect before the test releases it. Reply bounds are
10 s barriers, not part of the property: a write that was queued instead of
rejected can only be answered after the gate opens, which never happens first.
Evidence: with a 1.2 s slow actor start modelled (UpdateConnectionHealth
Connecting sleeps), the old body passed 0/30 and the new one 30/30. Unmodified,
the new test passed 40/40 under 14 busy-loop CPU load. Mutations still caught:
Connecting dropping writes (timeout) and Connecting performing writes.
Claude-Session: https://claude.ai/code/session_01GT67AEHd2Acv1YPwGfXEoV
Joseph Doherty
65ffa1dad4