CircleCI job 22 failed with turnCount 19 instead of 20. A writer thread
died with ConcurrentModificationException: QQQ's MemoryRecordStore.query
iterates a table's synchronized map without holding its lock, so one
writer's INSTANCE-row update (INSTANCE usage lock) raced another
writer's insert of a user row (a different usage lock). The exception
was swallowed by the virtual thread, so the test only saw a lost count.
The race is in the in-memory test backend, not in AssistantStore's
per-key locking. The writers now use a store whose individual backend
calls are atomic, as on a real database, so the per-key locks are still
the only thing protecting the read-modify-write under test. A start
latch releases all writers together, and an executor's futures surface
any writer exception as a test failure.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
james.maesandClaude Opus 5.5