Loading challenges
An async job API whose GET endpoint long-polls for a real status change instead of dumb fixed-interval polling -- measured at 15-30x fewer requests, not the "100x" round number a proxy-safe wait cap can't actually deliver.
Nobody has started this yet — be first.
No published tickets in this project yet.
About this project
An async job API: kicks off a simulated multi-step "transcode," and holds the request open until the job's status or progress actually changes, or seconds elapse, whichever comes first -- long-polling instead of naive fixed-interval polling. Two independent stores back each job: Redis () holds the job document (status, progress, result, error) as a TTL'd JSON blob, and an in-process registry () holds one per in-flight job, bumped on every write so a waiter that hasn't started waiting yet can never miss a wakeup. Real backs cancellation (not a status flag the worker ignores), a job's Redis key gets a TTL the moment it reaches a terminal status (refreshed to a longer TTL while still running), and an optional signed HMAC-SHA256 webhook callback fires on completion. The project's own README measures its signature claim -- long-polling costs far fewer requests than naive 1-second polling -- for real, landing at roughly 15-30x fewer requests depending on how chatty a job's progress reporting is, not the "100x" round number a proxy-safety-capped can't actually deliver.
Clone it
$git clone https://github.com/nishant1821/FastAPIDevTraining.gitHow to run it locally, step by step.
POST /jobsGET /jobs/{id}?wait=Nwaitapp/store.pyapp/registry.pyasyncio.Eventasyncio.Task.cancel()waitNine tickets are bugs deliberately injected into an otherwise-working codebase (a wrong Prometheus label on the success path, a min/max swap that breaks the wait cap in both directions at once, an inverted TTL selection, a webhook signature computed over bytes that were never actually sent, a swallowed asyncio.CancelledError, a registry race reintroduced by reusing instead of replacing an Event); six are enhancements that do not exist yet (a GET /jobs listing endpoint, an idempotency key that's accepted but ignored, a batch-submit endpoint, a retry endpoint, and a concurrency-cap capstone). Every ticket has its own dedicated, currently-failing pytest test, run individually by practice_tickets/run_tickets.sh so one hung/crashed ticket can't take down the whole run or hide another ticket's result -- and the README documents, with real captured output, exactly which four of these bugs also break the project's own tests/ suite and why the rest don't.