mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-24 11:58:31 -05:00
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/open-webui/open-webui/pull/18903
Author: @kjpoccia
Created: 11/3/2025
Status: ❌ Closed
Base:
dev← Head:fix/native-tool-results📝 Commits (2)
de1038fensure tool result displays consistently2cbf23dfallback comment for clarity📊 Changes
2 files changed (+24 additions, -3 deletions)
View changed files
📝
backend/open_webui/utils/middleware.py(+6 -1)📝
src/lib/components/chat/Messages/Markdown/MarkdownTokens.svelte(+18 -2)📄 Description
Implements the fix described in #18743
Pull Request Checklist
Note to first-time contributors: Please open a discussion post in Discussions and describe your changes before submitting a pull request.
Before submitting, make sure you've checked the following:
devbranch. Not targeting thedevbranch may lead to immediate closure of the PR.Changelog Entry
🧰 Fixed an issue where tool call results containing complex or unescaped characters (quotes, braces, Unicode, markdown syntax, etc.) were dropped from the Native tool-calling UI. Tool results now render reliably regardless of size or character composition.
Description
We were experiencing an issue with Native tool-calling where large or complex tool results would sometimes fail to display in the UI, even though the backend executed the tool successfully.
This affects any tools that return structured or verbose data (for example, RAG searches or JSON-based functions) where the result contains long text, nested objects, or special characters (quotes, braces, markdown, Unicode, etc.).
The issue stems from the current approach of serializing the tool result into an HTML attribute in middleware.py. That mechanism is fragile for large or irregularly escaped data, causing the attribute to be dropped during parsing and leaving the result section empty in the UI, even though backend logs confirm it was sent and processed correctly.
The proposed fix moves the result into the element content instead of an attribute, ensuring tool outputs are always preserved and visible to users.
Changed
extractResultFromDetailspull the tool result from the element, falls back to the "result" attribute for backward compatibilityFixed
Additional Information
Screenshots or Videos
Contributor License Agreement
By submitting this pull request, I confirm that I have read and fully agree to the Contributor License Agreement (CLA), and I am providing my contributions under its terms.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.