Skip to main content

Stop Draft

POST 
/v1/draft/stop

Tears down a draft-sync Job and its Redis state for one league - mode-agnostic (works for both live and practice). Does NOT delete the draft_config row: /status and a later /start re-launch both still need it, and there is no other stored copy of team_id/season/mode for that league once it's gone.

Scoped to app=draft-sync (not just league-id) so this can never delete some other workload that happens to share the league-id label. Waits for the Job's Pods to fully terminate (Foreground propagation + polling) before clearing Redis - a still-running listener could otherwise recreate the recommendation board or publish a target after this endpoint has already reported "stopped".

That wait proves this repo's own listener Job is gone, and - since issue #66 - the same wait now also covers a live league's connector (fantasy-browser-worker's draft_sync.js), if it was launched via /start?with_publisher=true and so carries the LIVE_SYNC_APP_LABEL this endpoint can discover. A connector started out-of-band instead (a manual kubectl apply of fantasy-browser-worker/k8s/test-draft-sync-job.yaml) carries no such label and is invisible here, exactly like before #66. So draft:{league}:picks/health and draft_picks:{league} are only cleared automatically when this call itself found and confirmed the connector's death; otherwise clearing them while an unknown connector might still be running risks losing a live pick or letting it recreate the keys right after this endpoint clears them. confirm_publisher_stopped=True remains the fallback for that out-of-band case: the caller manually asserting - by whatever means they verified it outside this API - that the publisher is truly stopped. Without one or the other, restarting a listener against a reused live league id replays the previous draft's picks and silently drops the new ones as duplicates.

Request​

Responses​

Successful Response