Skip to content

mason: prune dangling tool calls when replaying OpenAI session history - #551

Open
elainewang-db wants to merge 1 commit into
databricks:mainfrom
elainemwang:fix-dangling-tool-call
Open

mason: prune dangling tool calls when replaying OpenAI session history#551
elainewang-db wants to merge 1 commit into
databricks:mainfrom
elainemwang:fix-dangling-tool-call

Conversation

@elainewang-db

Copy link
Copy Markdown
Contributor

A run that dies during or right after a tool call persists the function_call item without its matching function_call_output, so the next turn replays a dangling call_id and the Responses API rejects the whole request with BAD_REQUEST. Wrap every session (durable and in-memory) so get_items drops unpaired tool calls/outputs on replay; writes and rollback pass through unchanged.

When a run interrupts for human approval, the Agents SDK persists the
`function_call` item immediately but writes its matching `function_call_output`
only on resume. If that resume never lands cleanly — the user declines, or the
paused in-process RunState is lost to a restart or another replica so the next
prompt starts a fresh turn — the transcript keeps a `function_call` with no
output. Replaying it makes the Responses API reject the whole request with
BAD_REQUEST for the dangling `call_id`.

Wrap every session (durable and in-memory) so `get_items` drops unpaired tool
calls/outputs on replay; writes and rollback pass through unchanged. (A plain
tool exception does NOT trigger this — the SDK stores an error output as a
matched pair; verified via an end-to-end HITL-interrupt test.)

Co-authored-by: Isaac <no-reply@databricks.com>
@elainemwang
elainemwang force-pushed the fix-dangling-tool-call branch from 2cbbf26 to 38b95f5 Compare September 4, 2026 22:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant