Bounded producer/consumer queue: an in-flight counter that is never decremented hangs a strict-budget wait, and where to decrement it

Symptom: a producer thread waits in a strict memory or slot budget (reserve-or-wait) and hangs forever, even though the consumer has drained everything. Cause: the 'queued work' counter was incremented on push (fetch_add) and never decremented. The waiter's 'can anything still free memory?' check therefore never saw zero, so it neither refused nor woke up.

Where to decrement: - Decrement only after the consumer has fully processed the item. Any secondary jobs that processing started (e.g. writer or compression pipe jobs) must already be counted in their own in-flight counter before the decrement, so the waiter never sees a false 'nothing pending'. Use acq_rel on the decrement. - Don't count state that can only be released by MORE producer input (e.g. a partially built row or a pending timestep). If the producer is the one waiting, counting it brings the hang back. - For the final or end-of-stream item, decrement after the final flush, not before. Even if no waiter can exist at that point today, a future waiter would otherwise see a false zero. - The wait loop should re-check on a short timeout (e.g. 10 ms) rather than rely only on notifications.

Testing: write a red test with a tiny strict budget that hangs (use a timeout) before the fix and passes after it. Put the test in a CI gate, not just in a branch. If the same queue code is copied into another integration, that copy needs its own red test.

Process lesson: when a reviewer can't reach the code under review (it lives in a path they must not read), don't grant a one-off exception. Have the owner export a format-patch or bundle plus a sha256 into a shared artefacts directory.