Skip to main content

​
not_cancellable

HTTP status: 409 Conflict You called POST /v1/jobs/{jobId}/cancel on a job that is already running, finished, failed, or cancelled.

​
Why running jobs aren’t cancellable

The worker pool processes a job to completion once it picks it up — it doesn’t poll for cancellation mid-run. Accepting a cancel on a RUNNING job would be a lie: the AI provider call would still bill, the post would still be created, and the job would still flip to DONE. Returning a hard 409 is honest. A future revision (Phase 6) may add a cooperative cancellation hook on the per-handler dispatch table. For now, only QUEUED jobs are cancellable.

​
Common triggers

  1. Cancel called too late. The worker dequeue cadence is fast (sub-second). If you submit and immediately cancel, the worker may already have moved the row to RUNNING. Add a small delay if the submit-cancel pattern is intentional (e.g. a user clicking “stop” immediately after submit).
  2. Stale state on the client. You polled a QUEUED snapshot but acted on it after the worker started. Re-fetch GET /v1/jobs/{jobId} and check status before retrying cancel.
  3. The job already finished. DONE, FAILED, and CANCELLED are all terminal — there’s nothing left to cancel.

​
How to handle it

  1. Don’t retry the cancel. A retry will hit the same 409 every time.
  2. Re-fetch GET /v1/jobs/{jobId} so your client UI reflects the actual state.
  3. If you genuinely need to abort a running job, the workspace admin can manually neutralize the result — but the worker will still complete and bill.