From e584a4c8c0ce8574817feff996104184af69c7ff Mon Sep 17 00:00:00 2001 From: alliscode Date: Tue, 28 Apr 2026 17:07:32 -0700 Subject: [PATCH] Don't clear pending_requests after restore-only pre-pass Pending requests in the restored checkpoint represent genuinely outstanding HITL requests. The next user input may carry function responses (Responses API `function_call_output` items become FunctionResultContent / FunctionApprovalResponseContent), which `WorkflowAgent._process_pending_requests` correctly extracts and matches against the populated `pending_requests`. Clearing them after restore would silently drop that state and force the next turn to be treated as a fresh input even when the caller is responding to the outstanding requests. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- .../agent_framework_foundry_hosting/_responses.py | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/python/packages/foundry_hosting/agent_framework_foundry_hosting/_responses.py b/python/packages/foundry_hosting/agent_framework_foundry_hosting/_responses.py index 103a7273ba..7da9e8413a 100644 --- a/python/packages/foundry_hosting/agent_framework_foundry_hosting/_responses.py +++ b/python/packages/foundry_hosting/agent_framework_foundry_hosting/_responses.py @@ -312,15 +312,11 @@ class ResponsesHostServer(ResponsesAgentServerHost): # If the restored checkpoint had pending request_info events, the # restore-only call replays them through # ``WorkflowAgent._convert_workflow_event_to_agent_response_updates`` - # and populates ``self._agent.pending_requests``. That would route - # the subsequent ``run(input_messages, ...)`` call through - # :meth:`WorkflowAgent._process_pending_requests`, which expects - # function-response content and rejects plain text. The host's - # contract for plain-text user input is "treat as new turn", not - # "respond to outstanding request_info", so we clear - # ``pending_requests`` after the restore-only pre-pass. State - # (Conversation.*, Inputs.*, Local.*) lives in the workflow - # checkpoint and is unaffected by this clear. + # and populates ``self._agent.pending_requests``. That is the correct + # state: those requests are genuinely outstanding, and the next + # ``run(input_messages, ...)`` call may contain ``function_call_output`` + # items (carried as FunctionResult/FunctionApprovalResponse content) + # that fulfill them via :meth:`WorkflowAgent._process_pending_requests`. if latest_checkpoint_id is not None: if is_streaming_request: async for _ in self._agent.run( @@ -335,7 +331,6 @@ class ResponsesHostServer(ResponsesAgentServerHost): checkpoint_id=latest_checkpoint_id, checkpoint_storage=restore_storage, ) - self._agent.pending_requests.clear() # Now run the agent with the latest input response_event_stream = ResponseEventStream(response_id=context.response_id, model=request.model)