Python: unknown-call termination leaves service-managed conversations unresolved

[CorgiBoyG]

Description

With terminate_on_unknown_calls=True, an unknown local function call raises KeyError after a service-managed continuation has already been persisted, but the function-calling loop does not settle the unresolved server-side call before propagating the exception.

This leaves the session pointing at a hosted response whose function call has no terminal output. Response-ID and similar service-managed continuations can reject the next request over that session because the prior call remains unresolved.

The behavior is present on current main at 2c49f50cf08ebb6c1687146336f039051f159333.

Root cause

Both non-streaming and streaming loops update continuation state immediately after the model response:

self._update_function_invocation_continuation_state(...)

They settle dangling calls only when _process_model_function_calls(...) raises MiddlewareFailure:

try:
    function_processing = await _process_model_function_calls(...)
except MiddlewareFailure:
    await self._settle_dangling_service_function_calls(...)
    raise

Unknown-call termination is raised separately as a plain KeyError inside _try_execute_function_call_groups(...), so it bypasses that settlement path.

Reproduction

client = MockBaseChatClient()

@tool(name="known_func")
def known_func(value: str) -> str:
    return value

client.function_invocation_configuration["terminate_on_unknown_calls"] = True
client.run_responses = [
    ChatResponse(
        messages=Message(
            role="assistant",
            contents=[
                Content.from_function_call(
                    call_id="u1",
                    name="unknown_func",
                    arguments={},
                ),
                Content.from_function_call(
                    call_id="k1",
                    name="known_func",
                    arguments={"value": "x"},
                ),
            ],
        ),
        conversation_id="conv_123",
    )
]

session = AgentSession()
agent = Agent(client=client, tools=[known_func])

with pytest.raises(KeyError, match="unknown_func"):
    await agent.run("run", session=session)

assert session.service_session_id == "conv_123"
assert client.call_count == 2  # fails: actual value is 1

Observed:

exception=KeyError:'Error: Requested function "unknown_func" not found.'
conversation_id=conv_123
call_count=1

The same missing settlement boundary exists in the streaming loop.

Expected behavior

The configured fail-closed KeyError should still reach the caller, but a service-managed conversation must first receive one terminal error result per unresolved local function call, with tool calling disabled, just as it does for MiddlewareFailure.

Sessions without a service-managed continuation should not incur an extra model request.

Implementation considerations

A focused fix should:

• distinguish unknown-call termination from unrelated KeyError exceptions;
• settle the original unresolved batch in both streaming and non-streaming paths;
• preserve the public KeyError behavior;
• advance response-ID continuation state to the settlement response;
• keep settlement best-effort so settlement failure never masks the original abort;
• cover both service-managed and ordinary sessions.

This should remain separate from mixed-batch precedence work: the defect already reproduces with an ordinary unknown-call batch on main.

I can prepare a focused fix and regression coverage after the core team confirms the intended exception/settlement boundary.

AI assistance was used for call-path analysis and drafting. The reproduction above was executed against an isolated checkout of the cited main commit.

[github-actions]

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

Agent analysis

Repro: python/packages/core/agent_framework/_tools.py::_get_response_with_function_invocation and _stream_response_with_function_invocation leave service-managed calls unsettled when _try_execute_function_call_groups raises the configured unknown-call KeyError. Trigger this with terminate_on_unknown_calls=True, an unknown function call, and a response carrying conversation_id. The minimal tests assert the KeyError, persisted session ID, and two service calls; both observe only one call.

• Failing test: python/packages/core/tests/core/test_function_invocation_logic.py
• Files examined: python/packages/core/agent_framework/_tools.py, python/packages/core/tests/core/test_function_invocation_logic.py, python/packages/core/tests/core/conftest.py, docs/specs/004-python-function-calling-loop.md, python/packages/core/pyproject.toml
• Tests run: existing terminate_on_unknown_calls tests, test_unknown_call_termination_setles_service_managed_conversation, test_streaming_unknown_call_termination_setles_service_managed_conversation
• Current version: 1.17.0

[manjunathshiva]

I verified this on main rather than relying on the label. _tools.py:1803-1804 raises a plain KeyError when terminate_on_unknown_calls is set and the name is absent from tool_map, and the only settlement on the failure path is inside the except MiddlewareFailure: handlers at :3344 and :3579. A bare KeyError isn't caught by either, so it propagates with the service-side call still unresolved.

For completeness, the other two _settle_dangling_service_function_calls call sites (:3267, :3427) are the nested settle_approval_replay_calls helper on the approval-replay path, so they don't cover this case either. The diagnosis in the issue holds.

Before doing anything further: _tools.py is covered by the Contribution ownership clause in docs/specs/004-python-function-calling-loop.md, so I'm asking rather than opening a PR. May I take this?

If yes, I'd want your view on shape before writing code, because settling a call that terminates the run interacts with the rule about not emitting unpairable results — whether settlement should happen for the unknown call only, or for every dangling call in the same batch, is a semantics decision I don't think I should make unilaterally.

Eduard van Valkenburg (@eavanvalkenburg) — you're bot-assigned here, and this is the same ownership boundary moonbox3 tagged you on in #8078, so one answer would cover both.

[CorgiBoyG]

Thanks for independently checking the remaining settlement paths. I opened this after tracing the failure through both function-calling loops, reproducing it on current main in non-streaming and streaming modes, and isolating the missing settlement boundary. I have also scoped the implementation and regression matrix, including service-managed versus ordinary sessions and preservation of the original KeyError.

I have deliberately held off on the production change because unknown-only versus batch-wide settlement is a runtime contract decision covered by the contribution-ownership guidance. Once the core team confirms that boundary, I plan to complete the focused fix and validation.

To avoid duplicate implementations, let's wait for Eduard van Valkenburg (@eavanvalkenburg)'s direction. If the team prefers a different ownership split, I'm happy to coordinate on the regression matrix and review.

[manjunathshiva]

Agreed on all counts, and it's your issue — I won't open a draft. Waiting for Eduard van Valkenburg (@eavanvalkenburg) on the settlement contract is the right sequence.

One thing that may save you a review cycle: spec 004's change-sensitivity list requires any change in this area to identify the affected rows in its scenario matrix and name a primary regression test for each. That was raised on my #8078, and requirement 1 is explicitly the core team's call rather than the contributor's — so it's worth asking which rows apply at the same time as the settlement question, rather than after the diff exists.

[CorgiBoyG]

Good point, thank you. Eduard van Valkenburg (@eavanvalkenburg), when you have a chance, could you confirm both parts of the contract?

1. On unknown-call termination, should settlement cover only the unknown call, or every dangling local call in the original batch?
2. Which rows in the spec 004 scenario matrix should be treated as affected, so I can pair each one with a primary regression test?

I'll keep the implementation on hold until that guidance is clear.