OpenAIResponsesLlm drops reasoning items between tool calls (never replayed or chained) #8110

🔴 Required Information

Describe the Bug:

OpenAIResponsesLlm never sends a model's reasoning back to OpenAI. As a result, in every tool loop the model starts its reasoning again from scratch after each tool call.

Two things combine to cause this:

1. Reasoning parts are skipped when history is rebuilt. _content_to_response_input_items calls _skip_replayed_reasoning_part for every thought part (call site). Its docstring says the thought parts don't carry reasoning item IDs, and that continuity comes from previous_response_id.
2. previous_response_id is never set for this model. _get_response_create_kwargs uses llm_request.previous_interaction_id (L1187). The flow fills that field only for Gemini with use_interactions_api (_interactions.py L123). It is also unusable with store=False.

So the reasoning is neither replayed nor chained. Nothing reports this: the API accepts the request without the reasoning items.

The data needed for a fix is already captured. _reasoning_parts puts encrypted_content in each thought part's thought_signature. It also records the reasoning item id (L623), but only in the response-level custom_metadata['openai_response']['reasoning'] (L698). The id is not stored on the part, so _content_to_response_input_items can't rebuild the item.

Why it matters: OpenAI's function calling guide says reasoning items "must also be passed back with tool call outputs". Its reasoning guide describes stateless use: with store: false, pass back all output items in their original order, and reasoning items carry encrypted_content.

Steps to Reproduce:

1. Install google-adk[openai]==2.14.0. I also checked main, which still skips reasoning parts at the same place.
2. Run the contributing/samples/models/openai_responses_reasoning agent with OPENAI_MODEL=gpt-6.1-terra, with a prompt that makes the model reason and call tools across several steps.
3. Subclass OpenAIResponsesLlm and log the type of every item in kwargs["input"] from _get_response_create_kwargs. Also log custom_metadata["openai_response"]["reasoning"] on each response.

class LoggingResponsesLlm(OpenAIResponsesLlm):
    def _get_response_create_kwargs(self, llm_request, *, stream):
        kwargs = super()._get_response_create_kwargs(llm_request, stream=stream)
        print([i.get("type", "message") for i in kwargs["input"]],
              kwargs.get("previous_response_id"))
        return kwargs

Expected Behavior:

Each request after a tool call includes the earlier reasoning items ({type, id, summary, encrypted_content}) in their original positions, before the function_call items they came with. Alternatively, it chains with previous_response_id when store is enabled.

Observed Behavior:

Every response returned one reasoning item with id and encrypted_content, but no later request contained a reasoning item, and previous_response_id was always None:

call 1 input: [message]
call 2 input: [message, function_call x3, function_call_output x3]          # no reasoning
call 3 input: [... , function_call, function_call_output]                   # no reasoning
call 4 input: [... , message, message]                                       # no reasoning
previous_response_id: None on every call

Environment Details:

• ADK Library Version: 2.14.0 (also checked main)
• Desktop OS: macOS
• Python Version: 3.13

Model Information:

• Are you using LiteLLM: No (OpenAIResponsesLlm)
• Which model is being used: gpt-6.1-terra (the bug is in the adapter, not the model)

🟡 Optional Information

A working fix, tested live:

A subclass that overrides _get_response_input and adds each reasoning item back in its original position fixes this. It looks up the item id from the captured custom_metadata by encrypted_content, groups summary parts by item, and writes {"type": "reasoning", "id", "summary": [...], "encrypted_content"}. With store=False, OpenAI accepted every replayed item with no errors (up to 72 reasoning items in one run).

Suggested upstream change:

• Keep the reasoning item id on each thought part (for example in part_metadata) along with the encrypted_content already in thought_signature.
• In _content_to_response_input_items, rebuild one reasoning item per original item, unchanged and in order, instead of skipping it.
• Replay only to the model that produced it. Encrypted reasoning is tied to its model family.

Small A/B comparison (gpt-6.1-terra, effort high, store=False, 3 runs per cell, a unique instruction nonce per run so runs can't share caches):

These short tasks used little reasoning, and replay showed no gain in correctness. It increased input tokens, because replayed items count as input. I'm including this for transparency. The gap is still a correctness issue against OpenAI's documented contract; the quality effect should show on long, reasoning-heavy tool loops, which this sample doesn't cover.

Acceptance criteria (each checkable with a mocked HTTP test):

• After a response containing a reasoning item followed by a function_call, the next request's input contains that reasoning item (same id, summary and encrypted_content) right before the replayed function_call.
• A reasoning item with several summary parts is replayed as one item, not one per part.
• A reasoning item with encrypted_content and no summary is still replayed.
• The same holds when the response is streamed (StreamingMode.SSE).
• Reasoning from a different model is not replayed.

Suggested priority / effort: P2 (silent loss of model state, no crash); small to medium effort, in _reasoning_parts, _content_to_response_input_items and the stream accumulator, plus tests.

Related: #8109 (the same gap in LiteLlm for OpenRouter reasoning_details), #8029 (another Responses-adapter feature gap).

How often has this issue occurred?:

• Always (100%): every multi-step call with a reasoning model.