Loading challenges
Nobody has started this yet — be first.
Business impact
/readyz's binary ready/not-ready signal only tells an operator something is wrong at the same moment clients start getting hard 503s — there is no earlier warning that the queue is getting close to capacity. degraded already exists in /readyz's response body for exactly this purpose, but it's hardcoded False, so there is currently zero lead time between "queue has headroom" and "queue is full and rejecting requests."
Problem
GET /readyz already returns a degraded field, but it is hardcoded to False regardless of actual queue occupancy — there is no signal distinguishing comfortable headroom from a queue at 95% capacity.
Current behavior
With queue_depth=18 out of queue_max_size=20 (90% full), GET /readyz still reports degraded: false — readyz never reads queue.qsize() or queue.maxsize to compute it.
Expected behavior
degraded becomes True once queue_depth crosses a high-water-mark fraction of queue_max_size (e.g. 80%), while /readyz still returns 200 at that point — a warning, not a failure — and goes back to False if occupancy drops back below the threshold.
Steps to reproduce
pytest practice_tickets/tests/test_ticket_14_degraded_readiness.py -v — sets queue_depth=18 against queue_max_size=20 and confirms GET /readyz currently reports degraded: false.Why this matters
/readyz's binary ready/not-ready signal is the wrong shape for this — by the time it's False, requests are already failing. A separate degraded boolean lets /readyz keep meaning "should traffic be routed here at all" while adding a distinct, earlier warning signal a dashboard or alert rule can watch independently.
Suggested approach
readyz already depends on get_queue (it's wired in as a parameter, just unused right now) — look at what queue.qsize() and queue.maxsize give you, and how that compares to a reasonable "getting close" threshold.
Acceptance criteria
Verification
pytest practice_tickets/tests/test_ticket_14_degraded_readiness.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 feat/degraded-readiness-signalFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin feat/degraded-readiness-signalSubmit 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 2
Implement a feature
Extend the system within its own patterns.