Nobody has started this yet — be first.
Business impact
The only way to find out anything about a job today is GET /jobs/{id} -- which requires already knowing its id. There's no way to answer "what jobs currently exist" or "what's running right now" through the API at all; today that means reaching for direct Redis access (redis-cli KEYS 'job:*', or worse, SCAN in production), exactly the kind of direct-datastore access an API is supposed to make unnecessary.
Problem
There is no route registered for GET /jobs at all -- it only matches the path of the existing POST /jobs route, on a method that route doesn't accept.
Current behavior
GET /jobs returns 405 Method Not Allowed because no route is registered for it -- only POST /jobs exists at that path, and app/store.py has no function that enumerates job documents at all.
Expected behavior
GET /jobs returns a list of known jobs (id, status, progress at least) as {"jobs": [...]}, with an optional limit query param (rejecting non-positive values with 422 rather than silently returning nothing).
Steps to reproduce
pytest practice_tickets/tests/test_ticket_06_list_jobs_endpoint.py -vGET /jobs returns 405 Method Not Allowed -- no route exists for GET /jobs yet, only POST /jobs.Why this matters
Every job document already lives in Redis under a predictable job:{id} key prefix (see app/store.py's _KEY_PREFIX), so the data this needs already exists -- the gap is purely in exposing it. The natural implementation is a Redis SCAN over that prefix (not KEYS, which blocks the whole Redis instance on a large keyspace) followed by a batch read of the matched documents.
Suggested approach
app/store.py is the natural home for a new function that enumerates job ids/documents (mirroring create/load/update's existing shape). app/routers/jobs.py needs a new @router.get("/jobs") route -- think about what "no jobs yet" and an out-of-range limit should each return.
Acceptance criteria
Verification
pytest practice_tickets/tests/test_ticket_06_list_jobs_endpoint.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/list-jobs-endpointFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin feat/list-jobs-endpointSubmit 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:6379curl localhost:8000/healthz{"status": "ok", "redis": true}Work the tickets in practice_tickets/tickets/ (ordered easy → hard); each names one dedicated pytest file in practice_tickets/tests/:
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements-dev.txt
pytest practice_tickets/tests/test_ticket_01_completed_jobs_counted_as_failed.py -v # a single ticket
./practice_tickets/run_tickets.sh # all 15, clean pass/fail summary
Each ticket test runs in its own pytest process with a 60s timeout, so one hung/crashed ticket can't take down the whole run or hide another ticket's result. Run pytest tests/ (the project's own suite, against fakeredis, hermetic and fast) after each fix to check for regressions -- the README documents exactly which fixes are expected to change that suite's results.
Level 2
Implement a feature
Extend the system within its own patterns.