Nobody has started this yet — be first.
Business impact
There is no POST /jobs/{id}/retry. A client that wants to resubmit a failed or cancelled job today has to have kept its own copy of the original duration_seconds/steps/callback_url and issue a brand new POST /jobs from scratch -- and even if a route existed, it couldn't reconstruct those parameters on its own, because the job document doesn't persist the parameters it was submitted with at all. Once a job is running, its own original submission is already gone from anywhere the server can see it.
Problem
app/store.py's create() never writes duration_seconds/steps/fail into the document it stores, and app/schemas.py's JobDocument doesn't declare them either.
Current behavior
POST /jobs/{id}/retry returns 404 because the route doesn't exist, and even if it did, app/store.py's create() never writes duration_seconds/steps/fail into the stored job document, so there is nowhere to read a job's own original parameters back from.
Expected behavior
POST /jobs/{id}/retry on a job that has reached a terminal status (completed/failed/cancelled) creates a new job with the same parameters the original was submitted with, and returns its (different) job_id. The new job's document records where it came from (e.g. a retried_from field). Retrying a job that's still running is rejected (409) -- a live retry would spawn a second worker racing the first.
Steps to reproduce
pytest practice_tickets/tests/test_ticket_12_retry_endpoint_missing.py -vPOST /jobs/{id}/retry returns 404 -- the route doesn't exist yet, and the job document doesn't even persist the original submission's parameters to retry with.Why this matters
This ticket is really two things stacked on top of each other: the missing route, and the missing data it would need. Implementing the route without first fixing the data gap isn't possible -- there's nowhere to read the original duration_seconds/steps back from. That makes this a good exercise in "the visible ask is smaller than the actual gap" -- the honest scope here starts one layer below where the route itself lives.
Suggested approach
Start with what app/store.py's create() writes into a job document today, and what POST /jobs's currently has available (, , , the callback URL) that never makes it into that document. Once those are actually persisted, becomes: read the original document, reject if it isn't terminal, otherwise call the same job-creation path already uses with the original's parameters.
Acceptance criteria
Verification
pytest practice_tickets/tests/test_ticket_12_retry_endpoint_missing.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/retry-endpoint-missingFix it and commit
Meet every acceptance criterion, and add a test that would have caught this.
Push the branch
$git push -u origin feat/retry-endpoint-missingSubmit 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 increate_job()req.duration_secondsreq.stepsreq.failPOST /jobs/{id}/retrycreate_job()http://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.