Note

Medium Risk
Changes STM concurrency semantics for drain() by relying on a single counter updated on enqueue/complete, which could regress drain behavior under edge cases (failed offers, interruptions). Minor API/typing risk if callers relied on enqueue’s previous return type/behavior.

Overview
DrainableWorker now tracks both queued and in-flight work via a single STM outstanding counter that is incremented atomically in enqueue and decremented when process finishes.

drain() is simplified to retry solely based on outstanding > 0, removing the previous logic that also checked TxQueue.isEmpty and incremented the counter on take().

^{Written by Cursor Bugbot for commit 15905ec. This will update automatically on new commits. Configure here.}

Note

Make DrainableWorker drain off outstanding count atomically

• enqueue now atomically increments an outstanding counter alongside queuing the item in a single transaction, replacing the previous approach of incrementing on take.
• drain() waits until the outstanding counter reaches zero, which means it resolves only after all enqueued items have finished processing, not just when the queue is empty.
• The explicit TxQueue.isEmpty check in drain is removed, as the counter already subsumes it.
• Behavioral Change: drain() now accounts for items currently being processed, making it safe to use as a deterministic completion signal in tests.

^{Macroscope summarized 15905ec.}