A steady trickle of events never triggers the time-based flush

The whole design of this ingestion service rests on "a batch flushes when EITHER it fills up OR batch_max_wait_seconds elapses, whichever comes first." The time-based half of that guarantee currently only holds if events stop arriving entirely for the full wait window. If events keep trickling in — individually spaced further apart than they'd need to be to fill a batch, but closer together than batch_max_wait_seconds — the wait timer effectively never expires. In production this means any customer whose event rate is below "fills a batch every batch_max_wait_seconds" but above "goes fully silent" can have events sit in the queue far longer than the configured batch_max_wait_seconds promises — potentially indefinitely.

The whole design of this service rests on a batch flushing when it fills up OR batch_max_wait_seconds elapses, whichever comes first. The wait side of that guarantee only holds today if events stop arriving entirely for the full window — a steady trickle keeps pushing the deadline back out, so a batch below batch_max_size can sit unflushed far longer than batch_max_wait_seconds promises, potentially indefinitely.

1. pytest practice_tickets/tests/test_ticket_11_batch_timer_trickle.py -v — posts events one at a time, each arriving just under batch_max_wait_seconds after the last, well below batch_max_size; the batch never flushes even though the total elapsed time is many multiples of batch_max_wait_seconds.

This is the classic difference between a "deadline" (a fixed point in time, set once) and a "debounce"/"idle timer" (reset on every event) — both are legitimate patterns, but this function's contract calls for the former. Recomputing the deadline every loop iteration silently turns a bounded-wait-time guarantee into an unbounded one under continuous-but-sparse traffic — exactly the traffic pattern most likely to occur outside of a synthetic load test.

Look at where deadline is assigned inside the while loop in _collect_batch (app/flush.py). Compare it against how remaining is computed and used afterward. The batch's wait budget needs to be fixed relative to one point in time, not recalculated on every pass through the loop.