Activity

1. its-amann commented on Oct 21, 2026

   

   its-amann

   on Oct 21, 2026

   More actions

   @pcbeingused333, thanks for the repro. I'm working on preserving one ReasoningContent per Responses API reasoning item, including its ID and encrypted content, in both the normal and streaming paths.

   The approach is to let the existing ChatMessage.from_assistant(reasoning=...) parameter also accept a list, keeping the current string and single-item forms compatible. Streaming chunks would be grouped by output item instead of merging metadata across items. I'll add regression tests for multiple reasoning items, encrypted-only items, and conversion back to API input.

   @anakin87, please let me know if this is already being handled internally or if you prefer a different API shape.
2. anakin87 commented on Oct 21, 2026

   

   anakin87

   on Oct 21, 2026

   Member

   More actions

   Hello!

   Before discussing a solution, I'd like to see a reproducible end-to-end example using actual OpenAIResponsesChatGenerator executions, without mocks or manually constructed responses.
3. its-amann commented on Oct 21, 2026

   

   its-amann

   on Oct 21, 2026

   More actions

   Thanks @anakin87, that makes sense. The unit cases confirm that conversion drops items, but they don't establish that a live provider returns that shape.

   @pcbeingused333, could you share a minimal example using actual OpenAIResponsesChatGenerator.run() calls, along with the model/provider, relevant generation parameters, and SDK version? A redacted response showing the separate reasoning items would also help. Please leave out API keys and encrypted content.

   I'll hold off on opening a PR until we can reproduce the behavior end to end.
4. its-amann commented on Oct 21, 2026

   

   its-amann

   on Oct 21, 2026

   More actions

   @anakin87, I was able to reproduce this with actual OpenAIResponsesChatGenerator.run() calls against OpenAI, without mocks or constructed SDK responses.

   Tested with gpt-5-mini, OpenAI Python SDK 3.35.1, and Haystack main at 95ee53a:

   from haystack.components.generators.chat import OpenAIResponsesChatGenerator
   from haystack.dataclasses import ChatMessage
   
   # Set OPENAI_API_KEY in the environment. This makes paid API requests.
   stream = False  # Repeat with True to check streaming.
   chunks = []
   generator = OpenAIResponsesChatGenerator(
       model="gpt-5-mini",
       timeout=45,
       max_retries=0,
       tools=[
           {"type": "web_search", "search_context_size": "low"},
           {
               "type": "function",
               "name": "multiply",
               "description": "Multiply two integers exactly.",
               "parameters": {
                   "type": "object",
                   "properties": {"a": {"type": "integer"}, "b": {"type": "integer"}},
                   "required": ["a", "b"],
                   "additionalProperties": False,
               },
               "strict": True,
           },
       ],
       generation_kwargs={
           "max_output_tokens": 2048,
           "max_tool_calls": 1,
           "parallel_tool_calls": True,
           "reasoning": {"effort": "low", "summary": "auto"},
           "include": ["reasoning.encrypted_content"],
           "store": False,
       },
   )
   reply = generator.run(
       [ChatMessage.from_user(
           "Use web_search to find the year Python 3.0 was first released on python.org. "
           "Then use multiply to multiply that year by 7. Do the search before the multiplication tool call. "
           "Do not compute the product yourself."
       )],
       streaming_callback=chunks.append if stream else None,
   )["replies"][0]
   print(len(reply.reasonings), [r.extra.get("id") for r in reply.reasonings])

   In both modes the actual API output was reasoning, web_search_call, reasoning, function_call, with distinct reasoning IDs. On main, the message contained only the second ID. The streaming path also combined the two summaries into that single item.

   On the fix branch, both IDs survive in order and are included when the message is converted back to API input. I checked the encrypted payloads too: each non-streaming item and each streaming output_item.done payload is retained separately. Follow-up run() calls with the multiplication result completed successfully in both patched modes.

   For clarity, the follow-up also completed on main in the non-streaming check. This reproduces loss of earlier reasoning items; it does not demonstrate an API rejection. The live example uses a built-in search followed by a function call, rather than the issue's constructed example with two function calls.

   The branch also passes 388 focused unit tests, full type checking, applicable pre-commit hooks, and package builds. @pcbeingused333, does this match the scenario you had in mind?
5. pcbeingused333 commented on Oct 21, 2026

   

   pcbeingused333

   on Oct 21, 2026

   ContributorAuthor

   More actions

   Thanks @its-amann, yes, that is the scenario: a single Responses API output with more than one reasoning item (one before each function call), where the converted ChatMessage only kept the last one. Glad it reproduces with live calls, and thanks for picking up the fix.
6. github-actions

   assigned

   sjrl

   on Oct 21, 2026