`test_parallel_sessions_append_every_message_once` asserted that more than
one of four sessions had appended something. ThreadPoolExecutor promises a
thread count, never that every worker takes an item from a shared iterator,
so a loaded host where one thread drains all 40 messages before its
siblings start fails the assertion with nothing broken. CI did exactly that
in run 40023932276; 25 local runs pinned to a single CPU did not.
The sessions now meet at a barrier before their first append. A pool that
runs them concurrently releases all four, and a serialised one reaches the
timeout and leaves the later sessions empty, which the assertion still
catches: with max_workers forced to 1 the test fails with the same
"1 not greater than 1" CI reported.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
kevinveenbirkenbachandClaude Opus 5
657015852a