github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-16 06:03:26 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #24500] feat: apply filter in tool call loop #91056

New Issue
Closed
opened 2026-05-15 16:19:37 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-05-15 16:19:37 -05:00
Owner
Copy Link

Originally created by @tjc0726 on GitHub (May 9, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24500

Check Existing Issues

  • I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

  • I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

Currently, process_pipeline_inlet_filter is only executed once on the initial user request.

In backend/open_webui/utils/middleware.py, when a model triggers a tool, the internal retry loop (while len(tool_calls) > 0...) appends the tool results to the messages array and directly invokes generate_chat_completion().

The problem for me is the reasoning content, although in 0.9.4, it determines how to reconstruct reasoning history based solely on the provider string (e.g., llama.cpp maps to reasoning_content, while the default strips it), However, even it's not llama.cpp, various "OpenAI-compatible" endpoints have different requirements for passing reasoning history:
eg.
DeepSeek API also expects it in the reasoning_content field.
OpenRouter expects it in the reasoning_details field.

As #23339 mentioned, this should be handled by a filter, however when a model triggers a tool, the filter don't apply to it in the tool call loop, causing some model e.g. deepseek stop response after a tool call.

Also, things get complicated after 0.9.3, because the reaoning content, which previous wraped in , is already stripped, making extract reasoning content in filter impossible when it's openai endpoint.

related issue #23844 #23843 #23339

Desired Solution you'd like

apply filter in tool call loops
somehow make thinking content visiable to filter again? I have no idea either

Alternatives Considered

No response

Additional Context

No response

Originally created by @tjc0726 on GitHub (May 9, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24500 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description Currently, process_pipeline_inlet_filter is only executed once on the initial user request. In backend/open_webui/utils/middleware.py, when a model triggers a tool, the internal retry loop (while len(tool_calls) > 0...) appends the tool results to the messages array and directly invokes generate_chat_completion(). The problem for me is the reasoning content, although in 0.9.4, it determines how to reconstruct reasoning history based solely on the provider string (e.g., llama.cpp maps to reasoning_content, while the default strips it), However, even it's not llama.cpp, various "OpenAI-compatible" endpoints have different requirements for passing reasoning history: eg. DeepSeek API also expects it in the reasoning_content field. OpenRouter expects it in the reasoning_details field. As #23339 mentioned, this should be handled by a filter, however when a model triggers a tool, the filter don't apply to it in the tool call loop, causing some model e.g. deepseek stop response after a tool call. Also, things get complicated after 0.9.3, because the reaoning content, which previous wraped in <thinking>, is already stripped, making extract reasoning content in filter impossible when it's openai endpoint. related issue #23844 #23843 #23339 ### Desired Solution you'd like apply filter in tool call loops somehow make thinking content visiable to filter again? I have no idea either ### Alternatives Considered _No response_ ### Additional Context _No response_
GiteaMirror commented 2026-05-15 16:19:38 -05:00
Author
Owner
Copy Link

@owui-terminator[bot] commented on GitHub (May 9, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

  1. 🟣 #18222 feat: Enable Filter inlet function on tool call continuations
    This is directly about filter inlet functions not running on tool call continuations, which is the same core request as applying filters inside the tool-call loop.
    by Algorithm5838

  2. 🟣 #23175 issue: reasoning_content is stripped from assistant tool call messages, breaking multi-turn tool calling with reasoning models (Kimi K2.5, etc.)
    This issue reports that reasoning_content is stripped from assistant tool-call messages, causing multi-turn tool calling to fail with reasoning models. That matches the reasoning-history loss described here.
    by estemit · bug

  3. 🟣 #19328 feat: Support reasoning_details across tool steps (currently breaks Gemini 3 pro + native function calling)
    This is the OpenRouter equivalent of the same problem: reasoning_details are dropped across tool steps, breaking Gemini/OpenRouter function calling.
    by ciejer

  4. 🟣 #20926 issue: deepseek-reasoner stops response after first tool call
    This is a concrete symptom of the same DeepSeek reasoning/tool-call interaction where the model stops after the first tool call, matching the user's DeepSeek example.
    by filiptrplan · bug

  5. 🟣 #23879 issue: reasoning_content is ignored in non-stream openai API
    This issue is about reasoning_content being ignored in the OpenAI API path, which overlaps with the user’s concern that reasoning content is not preserved/available for tool-call follow-up requests.
    by vanmilleru · bug

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

<!-- gh-comment-id:4412932319 --> @owui-terminator[bot] commented on GitHub (May 9, 2026): <!-- terminator-bot:related-issues-reply --> 🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟣 [#18222](https://github.com/open-webui/open-webui/issues/18222) **feat: Enable Filter inlet function on tool call continuations** *This is directly about filter inlet functions not running on tool call continuations, which is the same core request as applying filters inside the tool-call loop.* *by Algorithm5838* 2. 🟣 [#23175](https://github.com/open-webui/open-webui/issues/23175) **issue: reasoning_content is stripped from assistant tool call messages, breaking multi-turn tool calling with reasoning models (Kimi K2.5, etc.)** *This issue reports that reasoning_content is stripped from assistant tool-call messages, causing multi-turn tool calling to fail with reasoning models. That matches the reasoning-history loss described here.* *by estemit · `bug`* 3. 🟣 [#19328](https://github.com/open-webui/open-webui/issues/19328) **feat: Support `reasoning_details` across tool steps (currently breaks Gemini 3 pro + native function calling)** *This is the OpenRouter equivalent of the same problem: reasoning_details are dropped across tool steps, breaking Gemini/OpenRouter function calling.* *by ciejer* 4. 🟣 [#20926](https://github.com/open-webui/open-webui/issues/20926) **issue: deepseek-reasoner stops response after first tool call** *This is a concrete symptom of the same DeepSeek reasoning/tool-call interaction where the model stops after the first tool call, matching the user's DeepSeek example.* *by filiptrplan · `bug`* 5. 🟣 [#23879](https://github.com/open-webui/open-webui/issues/23879) **issue: reasoning_content is ignored in non-stream openai API** *This issue is about reasoning_content being ignored in the OpenAI API path, which overlaps with the user’s concern that reasoning content is not preserved/available for tool-call follow-up requests.* *by vanmilleru · `bug`* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.
GiteaMirror commented 2026-05-15 16:19:39 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (May 10, 2026):

Intended behaviour for inlet, but open to discussion here.

<!-- gh-comment-id:4415754683 --> @tjbck commented on GitHub (May 10, 2026): Intended behaviour for `inlet`, but open to discussion here.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#91056
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?