Python: [Bug]: Resuming a background response with stream=True re-runs tools on every tool-loop iteration

[alanhuangyoo]

Description

Resuming a background response with continuation_token and stream=True re-runs the local tools on every tool-loop iteration.

The non-streaming path fixed this in #5462 (#5394): once the background response completes, OpenAIChatClient pops continuation_token from the caller's options, because FunctionInvocationLayer reuses that dict. The streaming resume branch in _inner_get_response doesn't. After the resumed stream completes with a function call, the tool runs, the loop calls the client again with the same options, and the client takes the retrieve branch again instead of creating a response with the tool results. That repeats until max_iterations, and the run ends with "Function invocation limit reached before a final answer could be produced."

Tools with side effects (sending an email, writing a record) run once per iteration.

Code Sample

options = {"continuation_token": {"response_id": "resp_bg"}, "tools": [send_email]}
stream = client.get_response(messages, stream=True, options=options)
async for _ in stream:
    pass
final = await stream.get_final_response()

With responses.with_raw_response.retrieve returning a stream that completes with a send_email function call, and create returning a text answer:

stream=False: retrieve calls=1, create calls=1, tool executions=1, final text='Email sent.'
stream=True:  retrieve calls=5, create calls=0, tool executions=4, final text='Function invocation limit reached before a final answer could be produced.'
Agent stream resume (default max_iterations): retrieve calls=41, create calls=0, tool executions=40

Error Messages / Stack Traces

None; the run ends on the invocation-limit fallback text.

Package Versions

agent-framework-core 1.18.0, agent-framework-openai 1.14.3 (main at 1cd06c5)

Python Version

3.12

Additional Context

The streaming resume branch is _chat_client.py:726-758; the non-streaming pop is at :827-834. #7538 is a different, service-side problem with background tool loops. I have a fix with a test and will open a PR.

🤖 Generated with Claude Code

[github-actions]

🤖 Automated triage reproduction notes (agent-authored — trust but verify)

Agent analysis

Repro: python/packages/openai/agent_framework_openai/_chat_client.py::_inner_get_response lines 726-758 retains continuation_token after a completed resumed stream containing a local function call, causing FunctionInvocationLayer to retrieve and execute it repeatedly. Minimal repro: mock streaming retrieval to return send_email, mock create to return text, then call get_response(..., stream=True) with a continuation token and max_iterations=2; it retrieves 3 times, creates 0 times, executes the tool twice, and returns the invocation-limit fallback.

• Failing test: python/packages/openai/tests/openai/test_openai_chat_client.py::test_streaming_completed_background_resume_does_not_repeat_tool_calls
• Files examined: python/packages/openai/agent_framework_openai/_chat_client.py, python/packages/core/agent_framework/_tools.py, python/packages/openai/tests/openai/test_openai_chat_client.py, python/packages/openai/pyproject.toml
• Tests run: test_streaming_response_completed_no_continuation_token, test_streaming_completed_background_resume_does_not_repeat_tool_calls
• Reported version: agent-framework-openai 1.14.3
• Current version: agent-framework-openai 1.14.3

[he-yufeng]

Verified against current main (7a82595): the bot's mechanism holds, and there is a precise reason the two modes disagree.

The non-streaming resume path already carries the fix from #5394: once the background response completes, _get_response drops continuation_token from the caller's options dict (_chat_client.py around line 832, with the comment naming the tool-loop hazard). The streaming resume branch in _stream (around lines 726-758) retrieves with stream=True and yields the resumed updates, but never drops the key. So after a completed resumed stream that contained a local function call, FunctionInvocationLayer reuses the same options dict for the next tool-loop iteration, and the client re-retrieves the finished response instead of POSTing the tool result — the double retrieval + double execution in your repro.

Direction I'd propose, mirroring the existing fix rather than inventing a new contract: when the resumed stream finishes with no further continuation token on the final response, drop continuation_token from the caller's options the same way the non-streaming branch does (options.pop("continuation_token", None), keep background so later iterations still create background responses). The seam is right after the resumed event stream drains — the final update's continuation state tells us the background response is done.

I can open the linked draft PR with that fix plus a regression test shaped like the bot's minimal repro (mock retrieve returning a completed stream with a local function call, then assert the second tool-loop iteration POSTs instead of re-retrieving). Say the word and I'll put it up.