`run()` abort with `conversationId` leaves orphan `function_call` items in the conversation store

[BrodaNoel]

Please read this first

• Have you read the docs? Agents SDK docs Yes
• Have you searched for related issues? Others may have faced similar issues. Yes

Describe the bug

When a streamed run() is aborted via its signal after the model has emitted one or more function_calls but before the SDK executes the tools and sends the corresponding function_call_outputs, those calls stay in the server-side conversation store without outputs. Any later run() against the same conversationId fails with:

400 No tool output found for function call call_XXX

Our use case

We run an SSE endpoint that pipes run(agent, input, { stream: true, conversationId, signal: controller.signal }) to the client. We wire controller.abort() to req.on('aborted') / req.on('close') to stop the run when the user closes the tab, refreshes, or loses the network. Whenever that happens mid tool-call, the conversation becomes unusable and we have to reconcile orphan items manually via the Conversations API.

Reproduction

const controller = new AbortController();
const stream = await run(agent, input, {
  stream: true,
  conversationId,
  signal: controller.signal,
});
for await (const e of stream) { /* consume */ }

Call controller.abort() while the model is streaming a function_call, then start a new run() against the same conversationId.

Root cause

In @openai/agents-core, run.js around the streamed response loop:

catch (error) {
  if (isAbortError(error)) {
    if (sentInputToModel) markInputOnce();
    await awaitGuardrailsAndPersistInput();
    return;
  }
  throw error;
}

The SDK returns without running resolveTurnAfterModelResponse / executeFunctionToolCalls, so no function_call_outputs are generated. With conversationId, OpenAI has already persisted the function_calls server-side as they streamed, and no cleanup is attempted.

(Tools that throw are handled correctly by defaultToolErrorFunction; corruption is specific to aborts that interrupt the turn after the model emitted the call but before tool execution.)

Suggested fix

On AbortError, before returning, emit a synthetic function_call_output (e.g. "" or "aborted") for each function_call the model already streamed in the current turn, so the conversation store stays consistent and reusable.

Debug information

• Agents SDK version: "@openai/agents": "^0.8.3",
• Runtime environment (e.g. Node.js 24.2.0)

Repro steps

it's super hard to get this code example. I have tried a lot of times, but it's super time-sensitive. The AbortController should call an abort riiiight in exact proper time.

Expected behavior

The conversation should not be corrupted.

[JahanzaibTayyab]

Hi @seratch, would love to take a stab at this. Posting a proposed approach first to confirm scope before opening a PR.

Proposed fix

In packages/agents-core/src/run.ts (around the streamed-response loop at L1170–1233), I'd:

1. Track function_call items as they're streamed — collect call IDs from event.type === 'response.output_item.added' (or equivalent) when the item type is function_call, into a pendingFunctionCalls: Map<callId, FunctionCallItem>.
2. Reconcile on response_done — clear entries whose tool outputs we know we'll execute below, so successful turns are unaffected.
3. In the isAbortError branch (L1225) — if serverConversationTracker?.conversationId is set AND pendingFunctionCalls is non-empty, POST synthetic function_call_output items to /v1/conversations/{conversationId}/items (one per orphaned call) before returning. Synthetic body: { output: 'aborted' } with status: 'incomplete' (matches the precedent set in fix: #1104 preserve incomplete status for rejected function tool outputs #1110 for rejected calls).

Open questions for you

1. Status value — should the synthetic output use status: 'incomplete' (consistent with fix: #1104 preserve incomplete status for rejected function tool outputs #1110) or 'completed' with a sentinel output? incomplete feels semantically right.
2. Output payload — is \"aborted\" acceptable as the default, or would you prefer something the model can identify as a control signal (e.g. JSON {\"_aborted\": true})?
3. previous_response_id mode — when only previousResponseId is set (no conversationId), the orphans aren't persisted server-side, so this fix is a no-op there. Confirming that's correct.
4. Failure mode — if the cleanup POST itself fails (network, 4xx), should we (a) swallow + log, (b) attach to a new error wrapping the original AbortError, or (c) re-throw? I'd lean (a) since the original abort is already user-initiated and the SDK shouldn't fail a deliberate cancellation.

Tests

Adding to packages/agents-core/test/run.stream.test.ts:

• Abort mid–function_call stream with conversationId → assert synthetic outputs are POSTed for each orphan.
• Abort with previousResponseId only → assert no cleanup POST.
• Abort before any function_call is emitted → assert no cleanup POST.
• Cleanup POST failure → assert original AbortError still propagates / is swallowed cleanly.

If this direction works for you, I'll open the PR. Happy to adjust based on your preferences on the open questions above. Thanks!

[anishesg]

Put together a fix in #1198.