Handle Late Tool Results After a GPT-6 Astra Task Is Cancelled

General
1

GPT-6 Astra can continue while your application runs an asynchronous tool, which means your application owns the awkward boundary between a user’s cancellation and the external job’s actual lifecycle. Treat those as two different facts.

Keep two cancellation states

Record task_cancelled when the user stops the Astra task. Separately track the external job as running, cancel_requested, stopped, completed, or unknown. A cancellation request is not proof that the job stopped. Only the job system’s own contract can establish that transition. If it offers cancellation, call it and persist the response; if it does not, keep the external state unknown rather than inventing success.

Make late results harmless by default

When a result arrives after task_cancelled, do not silently reopen the task or apply the result to a new attempt. Match it to the original job record, preserve the result for audit or an explicit recovery flow, and discard it from the cancelled task’s user-visible state. If your product intentionally supports recovery, require a new, explicit task to adopt the result and show that it came from late work. Keep the original job identity; an identifier alone does not make cancellation or retry safe.

A small state table makes the policy testable:

Task state External job state Late result Application action
active running no Accept only through the original correlation record.
cancelled cancel requested/unknown yes Keep inert; reconcile job state; do not reopen.
cancelled stopped yes Retain as a record; no task mutation.
cancelled completed yes Retain and require explicit recovery before use.

This design follows the guidance that the application executes asynchronous tools and manages pending work. It does not claim that Astra, or an external tool provider, supplies job termination or rollback. For every integration, document who can stop the job, what confirmation means, and how an unknown result is reconciled before allowing retries.

2

For an asynchronous retrieval tool, explicit recovery needs a data-validity check as well as user consent. The Astra guide says GPT-6 Astra can continue while the application runs a tool, with pending work still managed by the application. A late search result therefore needs an application policy for whether its evidence can enter a recovered task.

I would retain the original query, corpus or index revision, document versions, and retrieval time alongside the job identity, subject to the same access and retention rules as the underlying data. Before adopting that result, check the recovered task’s query and current document permissions. For a task requiring current information, also check whether the corpus has changed; if those checks cannot be established, run a fresh retrieval. Matching the original job proves correlation, but does not establish that its documents remain suitable evidence.

A useful hypothetical acceptance test is to cancel a task while retrieval is pending, then revoke access to one matching document before the result arrives. Start an explicit recovery task and verify that neither the document text nor its cached snippet enters the new model context. Repeat with unchanged permissions and corpus as a baseline, so the test checks the adoption decision rather than simply rejecting every late result. These are proposed application checks, not claims that Astra performs permission revalidation or that any retrieval experiment has been run.