Unexpected Behavior in Background Responses API – Status Changes from "Cancelled" to "Completed"

Question

Hello,

I'm experimenting with the Responses API in background mode using the GPT-4.1 model (non-streaming mode). I'm encountering unexpected behavior regarding job cancellation and status updates:

Scenario:

I send a very complex prompt that is expected to consume 10,000–20,000 tokens.

The request is initiated via background mode (stream: false).

I cancel the operation within a second after triggering it.

A GET request to the status endpoint shows status = cancelled, which is expected.

Issue:

When I re-trigger the same GET endpoint a few minutes later, I unexpectedly receive status = completed, and the full response payload is available.

Questions:

Is this a known behavior where background jobs continue processing even after being marked as cancelled?

Are there guarantees around the actual termination of processing upon cancellation?

Should clients implement additional logic to ignore a "completed" result for a previously "cancelled" task?

Is there a delay or race condition between issuing a cancel request and halting the actual execution on the backend?

Answer 1

Hello Sanjeet !

Thank you for posting on Microsoft Learn.

This is a known limitation in background job handling for Azure OpenAI Responses API (and similarly in OpenAI own platform APIs), cancellation requests do not guarantee immediate or complete termination of processing, especially for background jobs using stream: false.

Is it known that background jobs may complete after being cancelled?

Yes, this is known and expected behavior cancellation is "best effort" :

• the backend does not forcibly interrupt GPU/CPU execution mid-process, especially in non-streamed (long-run) tasks
• if cancellation is requested after the job is already picked up for execution, it might still complete

What are the guarantees around cancellation?

There are no hard guarantees that:

• the task will be terminated immediately
• the task won’t complete and return a response
• the backend resources will be freed right away

In short, cancellation is advisory, and due to backend constraints, some jobs will still run to completion.

Should clients ignore completed results of previously cancelled tasks?

Yes, your client-side logic should maintain a job-state map, for example:

{
  "job_id": "abc123",
  "status": "cancelled"
}

Then, if a later request to GET /jobs/abc123 returns "completed":

• you should discard the payload if your internal state marks it cancelled
• this ensures consistency from the user’s perspective

Is there a race condition between cancel and actual termination?

Yes, a race condition can occur:

• if the cancellation request reaches the backend after the job has been assigned to a worker (especially with large prompts), it may be too late
• status propagation (from "running" → "cancelled" or → "completed") may also lag slightly