[GH-ISSUE #18743] issue: Tool call results intermittently fail to display in UI when result data is large

GiteaMirror commented

2026-04-20 00:54:09 -05:00

Owner

Originally created by @kjpoccia on GitHub (Oct 30, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/18743

Originally assigned to: @tjbck on GitHub.

Check Existing Issues

I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.34

Ollama Version (if applicable)

No response

Operating System

macOS Sequoia and Windows 11

Browser (if applicable)

Safari 26.0.1, Chrome 141.0, Edge

Confirmation

I have read and followed all instructions in README.md.
I am using the latest version of both Open WebUI and Ollama.
I have included the browser console logs.
I have included the Docker container logs.
I have provided every relevant configuration, setting, and environment variable used in my setup.
I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
Start with the initial platform/version/OS and dependencies used,
Specify exact install/launch/configure commands,
List URLs visited, user input (incl. example values/emails/passwords if needed),
Describe all options and toggles enabled or changed,
Include any files or environmental changes,
Identify the expected and actual result at each stage,
Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

Tool call arguments and results should always display in the collapsible tool details UI
Results should render consistently regardless of size

Actual Behavior

Tool call with arguments displays correctly
Tool result section shows empty or displays as "" in the collapsed details view
Backend logs confirm the tool was executed and result was sent to the model
The model responds appropriately to the result, confirming it was received

Steps to Reproduce

Set up Open WebUI with native tool calling enabled
Create a tool that returns large JSON responses (e.g., RAG search returning 3+ document chunks amounting to 60k+ characters)
Invoke the tool through chat
Observe that the tool execution displays but the result content is missing from the UI
Check backend logs and generated chat response to confirm the result was actually generated and sent to the model

Logs & Screenshots

The issue isn't clear from logs alone - in the screenshot you can see that the tool result is not included in the collapsible component, however the model responds that it has received the documents.

Additional Information

Description

The current implementation in middleware.py stores the tool result in an HTML attribute:
tool_calls_display_content = f'<details type="tool_calls" done="true" ... result="{html.escape(json.dumps(tool_result, ensure_ascii=False))}" ...>'

This fails when:

Result data exceeds ~65k characters (practical HTML attribute limit)
Complex nested JSON with extensive escaping confuses the markdown parser
The marked library silently truncates or fails to extract large attributes

Proposed Fix

Move tool result data from HTML attributes into element content
Extract result from the token text before markdown parsing and pass to Collapsible component via attributes.
Use the extracted result instead of querying DOM or reading from attributes.

Impact

This affects any tool that returns substantial data
Users see incomplete tool execution UI, creating confusion about whether tools ran
The issue is intermittent based on result size, making it hard to debug

I have a working fix implemented locally and am prepared to submit a PR. The fix:

Moves result data out of HTML attributes and into element content
Extracts data during token processing before markdown parsing
Maintains backward compatibility with existing tool display logic
Supports dual format with fallback: The frontend will check for results in element content first (new format), then fall back to reading from attributes (old format), ensuring existing chat history and custom pipelines/functions that may rely on the results attribute within details continue to work

Originally created by @kjpoccia on GitHub (Oct 30, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/18743 Originally assigned to: @tjbck on GitHub. ### Check Existing Issues - [x] I have searched for any existing and/or related issues. - [x] I have searched for any existing and/or related discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.34 ### Ollama Version (if applicable) _No response_ ### Operating System macOS Sequoia and Windows 11 ### Browser (if applicable) Safari 26.0.1, Chrome 141.0, Edge ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior * Tool call arguments and results should always display in the collapsible tool details UI * Results should render consistently regardless of size <img width="991" height="422" alt="Image" src="https://github.com/user-attachments/assets/589ce016-71d5-4536-bb48-9ad104fa82ac" /> ### Actual Behavior * Tool call with arguments displays correctly * Tool result section shows empty or displays as "" in the collapsed details view * Backend logs confirm the tool was executed and result was sent to the model * The model responds appropriately to the result, confirming it was received <img width="1042" height="299" alt="Image" src="https://github.com/user-attachments/assets/1828fa7d-ad6f-4dac-93de-43d8330f387a" /> ### Steps to Reproduce * Set up Open WebUI with native tool calling enabled * Create a tool that returns large JSON responses (e.g., RAG search returning 3+ document chunks amounting to 60k+ characters) * Invoke the tool through chat * Observe that the tool execution displays but the result content is missing from the UI * Check backend logs and generated chat response to confirm the result was actually generated and sent to the model ### Logs & Screenshots The issue isn't clear from logs alone - in the screenshot you can see that the tool result is not included in the collapsible component, however the model responds that it has received the documents. <img width="1042" height="299" alt="Image" src="https://github.com/user-attachments/assets/e2e55e1c-bd98-4af1-9af6-aea16f7999da" /> ### Additional Information ## Description The current implementation in middleware.py stores the tool result in an HTML attribute: `tool_calls_display_content = f'<details type="tool_calls" done="true" ... result="{html.escape(json.dumps(tool_result, ensure_ascii=False))}" ...>'` This fails when: * Result data exceeds ~65k characters (practical HTML attribute limit) * Complex nested JSON with extensive escaping confuses the markdown parser * The marked library silently truncates or fails to extract large attributes ## Proposed Fix * Move tool result data from HTML attributes into element content * Extract result from the token text before markdown parsing and pass to Collapsible component via attributes. * Use the extracted result instead of querying DOM or reading from attributes. ## Impact * This affects any tool that returns substantial data * Users see incomplete tool execution UI, creating confusion about whether tools ran * The issue is intermittent based on result size, making it hard to debug I have a working fix implemented locally and am prepared to submit a PR. The fix: * Moves result data out of HTML attributes and into element content * Extracts data during token processing before markdown parsing * Maintains backward compatibility with existing tool display logic * Supports dual format with fallback: The frontend will check for results in element content first (new format), then fall back to reading from attributes (old format), ensuring existing chat history and custom pipelines/functions that may rely on the results attribute within details continue to work