Nobody has started this yet — be first.
Business impact
IngestQueue.put() is supposed to convert exactly one condition — the queue staying full for the entire timeout window — into a BackpressureError, which the router turns into a 503. The except clause currently catches any Exception, not just the asyncio.TimeoutError that asyncio.wait_for raises on a genuine timeout. If some other, unrelated bug ever raised an exception from inside this code path, it would be silently reclassified as ordinary backpressure — a 503, indistinguishable from the DB just being slow. Nobody gets paged, no error is logged as an error, and whoever's on call has no way to tell "the queue is genuinely full" apart from "something actually broke" from the outside.
Problem
IngestQueue.put() is supposed to convert exactly one condition — the queue staying full for the entire timeout window — into a BackpressureError. Its except clause catches any Exception, so an unrelated bug anywhere in that code path would be silently reclassified as ordinary backpressure.
Current behavior
IngestQueue.put wraps asyncio.wait_for(self._queue.put(record), timeout=self._put_timeout) in except Exception as exc: raise BackpressureError(...) from exc — far broader than the one asyncio.TimeoutError this function is documented to handle.
Expected behavior
Only asyncio.TimeoutError should be converted into BackpressureError; any other exception type should propagate unchanged so it surfaces as a loud failure instead of disguised backpressure.
Steps to reproduce
pytest practice_tickets/tests/test_ticket_12_queue_put_exception_type.py -v — replaces the internal queue's put() with something that raises a RuntimeError and confirms what IngestQueue.put() does with it.Why this matters
Catching Exception "just to be safe" is a common instinct, but it means the function can no longer distinguish "the specific thing I know how to handle" from "literally anything else that could possibly go wrong." That distinction is the entire value of a narrow except clause — it's what lets an unrelated bug fail loudly instead of being silently absorbed into a well-understood, already-monitored code path.
Suggested approach
Look at the except clause in IngestQueue.put (app/buffer.py). asyncio.wait_for raises a specific, well-documented exception type on timeout — which one, exactly, and how does that compare to what's currently being caught?
Acceptance criteria
Verification
pytest practice_tickets/tests/test_ticket_12_queue_put_exception_type.py -v
Hints (0/2)
Try it without hints first — the reading is the exercise.
Working on this ticket
Work on a branch named for the ticket — that's what you'll submit.
Branch off your fork
Sign in to create it automatically, or do it yourself:
$git checkout -b fix/queue-put-swallows-unrelated-errorsFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin fix/queue-put-swallows-unrelated-errorsSubmit it below
Paste your fork URL and the branch name, with a short write-up of the root cause.
Questions
Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.
Sign in to ask a question or reply.
Sign inhttp://localhost:8000localhost:5432curl localhost:8000/healthzcurl localhost:8000/readyzWork the tickets in practice_tickets/tickets/ (ordered easy → hard); each names one dedicated test in practice_tickets/tests/:
pytest practice_tickets/tests/test_ticket_01_persisted_count.py -v # a single ticket
./practice_tickets/run_tickets.sh # all 20, clean pass/fail summary
TICKET-17 needs a real Postgres to run at all (it checks which column a value lands in, which no fake/in-memory DB backend can meaningfully verify) — set TEST_DATABASE_URL=postgresql://<you>@localhost/ingest_test before running it or the full suite; without it, that one test is skipped, not failed.
Level 1
Fix a bug
Read existing behaviour, correct it.