Loading challenges
Nobody has started this yet — be first.
Business impact
GET /events/stats is the one place an on-call engineer can check a running instance's actual configuration without going and finding its environment variables. Two of the fields that are supposed to answer "how is this instance configured right now" — flush_workers and batch_max_size — are hardcoded to 0 no matter what the process was actually started with, so the endpoint gives a confidently wrong answer to exactly the question it exists to answer.
Problem
GET /events/stats reports live counters correctly, but returns flush_workers: 0 and batch_max_size: 0 unconditionally, regardless of the INGEST_FLUSH_WORKERS / INGEST_BATCH_MAX_SIZE values the process was actually started with.
Current behavior
get_event_stats in app/routers/events.py never reads the live Settings object — it hardcodes both flush_workers and batch_max_size to in the response instead of pulling them from , which already exists and already backs a the same way / do in this same handler.
Expected behavior
GET /events/stats reports the process's actual configured flush_workers and batch_max_size, sourced from the running Settings object, and reflects any change to either setting without further code changes.
Steps to reproduce
pytest practice_tickets/tests/test_ticket_03_stats_config_visibility.py -v — starts an app with flush_workers=7, batch_max_size=1234 and observes GET /events/stats reporting (0, 0) instead.Why this matters
app/dependencies.py::get_settings already exists and is exactly the FastAPI dependency this handler needs — it just isn't used here yet. This is as much about noticing an existing extension point as it is about writing new code.
Suggested approach
Look at how get_event_stats in app/routers/events.py already uses Depends(get_queue) and Depends(get_stats) to pull in what it needs. app/dependencies.py::get_settings follows the identical pattern.
Acceptance criteria
Verification
pytest practice_tickets/tests/test_ticket_03_stats_config_visibility.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/stats-config-visibilityFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin feat/stats-config-visibilitySubmit 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 in0app/dependencies.py::get_settingsDepends(...)get_queueget_statshttp://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.