Cancelled jobs aren't real asyncio cancellations, just a status flag

Nobody has started this yet — be first.

Business impact

This project's own README makes a specific, deliberate claim: cancelling a job is real asyncio.Task cancellation, not a status flag the simulated worker happens to also set. That distinction matters beyond API-response cosmetics -- imagine gating billing on whether a job was genuinely cancelled (task.cancelled()) versus completed some other way, specifically so a user who cancels their own job isn't charged for it. Right now, every "cancelled" job's underlying asyncio.Task actually reports as having finished normally. A billing check built on that ground truth would incorrectly treat every user-cancelled job as a normal completion -- and this is exactly the "looks right at the API layer, wrong one layer down" failure mode that black-box HTTP tests structurally cannot catch.

Problem

The cleanup (writing status="cancelled", bumping the metric, notifying the registry) all happens correctly, but the except block ends there -- there's no raise to let the CancelledError continue propagating, so the coroutine returns normally from asyncio's point of view.

Current behavior

run_job()'s except asyncio.CancelledError branch writes status="cancelled" and returns without a trailing raise, so the coroutine returns normally and task.cancelled() reports False even after a successful cancel.

Expected behavior

After POST /jobs/{id}/cancel, the underlying asyncio.Task that ran the job must itself report task.cancelled() is True -- not just the job document's status field.

Steps to reproduce

pytest practice_tickets/tests/test_ticket_13_cancellederror_swallowed.py -v
Or manually: submit a job, grab its asyncio.Task from the registry, call , then check .

Why this matters

This is the standard, well-documented asyncio pitfall: catching asyncio.CancelledError to run cleanup is completely correct and necessary, but the cleanup handler must re-raise it once done, or the cancellation itself is silently absorbed. It's an easy step to drop, because the symptom (the task's own terminal state) is invisible to anything that only checks the job document -- which is every existing black-box test in this project.

Suggested approach

Compare this except asyncio.CancelledError branch against the except Exception branch right below it in the same function: one of them ends by letting its exception continue propagating, the other doesn't (correctly -- a caught Exception here is meant to be fully handled, turned into a failed status, not re-raised). Which one should CancelledError behave like?

Acceptance criteria

After POST /jobs/{id}/cancel resolves, the job's underlying asyncio.Task reports task.cancelled() is True
The job document still correctly shows status="cancelled" (don't regress the existing, passing cancellation behavior)
POST /jobs/{id}/cancel's own response is unaffected (it already awaits the task and re-reads the document either way)

Verification

pytest practice_tickets/tests/test_ticket_13_cancellederror_swallowed.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

$git checkout -b fix/cancellederror-swallowed

Fix it and commit

Meet every acceptance criterion, and add a test that would have caught this.

Push the branch

$git push -u origin fix/cancellederror-swallowed

Submit it below

Paste your fork URL and the branch name, with a short write-up of the root cause.

Submit your fix

Questions

Stuck on something?

Ask about anything unclear in the ticket — the maintainer and anyone who has solved it can answer. Please don't post full solutions.

No questions yet. If something in this ticket reads ambiguously, you are probably not the only one — ask.

The project

Long-Polling Job Status API

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.

Fork on GitHub

Download

Setup

Long-Polling Job Status API

git clone <your-fork>
cd FastAPIDevTraining/job_status_api
cp .env.example .env
docker compose up --build   # Redis + FastAPI (uvicorn --reload, source bind-mounted)

The app is reachable at ; Redis at . A single worker process is used on purpose -- the long-poll mechanism's Event/Task pair lives in that process's memory (see the README's "Single-process design" section). Verify with ().