github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-06 19:08:59 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #21901] issue: Workspace tools never run in default (prompt-based) function-calling mode #58274

New Issue
Closed
opened 2026-05-05 22:46:20 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-05-05 22:46:20 -05:00
Owner
Copy Link

Originally created by @mlinares-tecnalia on GitHub (Feb 26, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21901

### 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 have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!).
- [x] I am using the latest version of Open WebUI.
### Installation Method
Docker
### Open WebUI Version
v0.8.5
### Ollama Version (if applicable)
_No response_
### Operating System
Ubuntu 22.04
### Browser (if applicable)
_No response_
### 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
With a workspace tool enabled for the chat and the model in default function-calling mode:
- The backend should call chat_completion_tools_handler so that:
  - The tool-calling prompt (and tool specs) is injected.
  - The task model (or equivalent path) can return a tool call (name + arguments).
  - The backend parses that response and executes the workspace tool (e.g. get_context_from_tecnalia).
- Logs should show: Tool call (default mode): name=... in_tools=True and Executing workspace tool: ..., followed by the tool’s own logs (e.g. MyTool RAG steps).
- The tool’s side effects (RAG query, citations, etc.) should occur and the final answer can use the tool result.
### Actual Behavior
With a workspace tool enabled and the model in default function-calling mode:
- Tools are loaded: logs show e.g. Chat tools loaded: 1 workspace tool(s) -> ['get_context_from_tecnalia'] and Chat tools (default/prompt): 1 tool(s) will be handled by tools handler.
- But chat_completion_tools_handler is never invoked: the code only logs and returns; it does not inject the tool prompt or run the tool.
- There are no log lines for "Tool call (default mode)" or "Executing workspace tool".
- The workspace tool code (e.g. MyTool ) never runs; no RAG call, no citations, no tool result in the conversation.
### Steps to Reproduce
1. Environment
- Open WebUI (version where the bug existed; fix is in backend/open_webui/utils/middleware.py).
- Backend run via Docker/Compose or local run; no special env vars required for this bug.
- One workspace tool installed (e.g. MyTool RAG) and visible under Workspace → Tools.
2. Model
- Use a model that uses default function calling (e.g. Qwen3-32B, or any model not set to “Native” in Admin → Settings → Models → Function Calling). Ensure the model has access to the workspace tool (e.g. tool enabled for that model or for the chat).
3. Chat
- Create a new chat.
- Select the model above.
- Enable the workspace tool for this chat (e.g. ➕ → select “MyTool RAG” or the relevant tool).
4. User action
- Send a message that should trigger the tool (e.g. “What do you know about Tecnalia?” or “Search for projects about X” so the task model would choose to call the tool).
5. Observe
- Expected: Tool runs (e.g. MyTool queries RAG, returns context/citations), and logs show Tool call (default mode): name=get_context_from_tecnalia in_tools=True and Executing workspace tool: get_context_from_tecnalia plus tool-specific logs.
- Actual (before fix): Tool does not run; no “Tool call (default mode)” or “Executing workspace tool” in logs; only “Chat tools (default/prompt): … will be handled by tools handler” and then normal chat completion without tool execution.
### Logs & Screenshots

2026-02-26T11:43:04.639272098Z 2026-02-26 12:43:04.638 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 200
2026-02-26T11:43:04.661293977Z 2026-02-26 12:43:04.661 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 200
2026-02-26T11:43:06.740250977Z 2026-02-26 12:43:06.739 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/tools/ HTTP/1.1" 200
2026-02-26T11:43:08.514841064Z 2026-02-26 12:43:08.514 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 304
2026-02-26T11:43:09.092512135Z 2026-02-26 12:43:09.092 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 200
2026-02-26T11:43:09.990089232Z 2026-02-26 12:43:09.989 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 304
2026-02-26T11:43:10.058351038Z 2026-02-26 12:43:10.058 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 304
2026-02-26T11:43:13.515415314Z 2026-02-26 12:43:13.515 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/7bad7aa5-3cf0-4466-a7c4-0860021a923d HTTP/1.1" 200
2026-02-26T11:43:15.217970487Z 2026-02-26 12:43:15.217 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 304
2026-02-26T11:43:19.777924297Z 2026-02-26 12:43:19.777 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 200
2026-02-26T11:43:25.355511062Z 2026-02-26 12:43:25.354 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 200
2026-02-26T11:43:29.010907526Z 2026-02-26 12:43:29.010 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "POST /api/v1/chats/new HTTP/1.1" 200
2026-02-26T11:43:29.038626930Z 2026-02-26 12:43:29.038 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/tools/ HTTP/1.1" 200
2026-02-26T11:43:29.071493935Z 2026-02-26 12:43:29.071 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200
2026-02-26T11:43:29.116171580Z 2026-02-26 12:43:29.115 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "POST /api/v1/chats/55e13486-f6a3-44c7-a8b0-6309509fcf80 HTTP/1.1" 200
2026-02-26T11:43:29.148716673Z 2026-02-26 12:43:29.148 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200
2026-02-26T11:43:29.152106035Z 2026-02-26 12:43:29.151 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 304
2026-02-26T11:43:29.211771500Z 2026-02-26 12:43:29.211 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "POST /api/chat/completions HTTP/1.1" 200
2026-02-26T11:43:29.247434505Z 2026-02-26 12:43:29.247 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200
2026-02-26T11:43:30.871058263Z 2026-02-26 12:43:30.870 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 200
2026-02-26T11:43:32.201734680Z 2026-02-26 12:43:32.200 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/55e13486-f6a3-44c7-a8b0-6309509fcf80 HTTP/1.1" 200
2026-02-26T11:43:32.399539797Z 2026-02-26 12:43:32.399 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "POST /api/v1/chats/7ad6b1ee-d895-4a47-9e2a-f415cb1eba2e HTTP/1.1" 200
2026-02-26T11:43:32.732243155Z 2026-02-26 12:43:32.731 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200
2026-02-26T11:43:32.993766415Z 2026-02-26 12:43:32.993 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "POST /api/chat/completions HTTP/1.1" 200
2026-02-26T11:43:33.034456939Z 2026-02-26 12:43:33.034 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200
### Additional Information
When workspace tools (e.g. custom Python tools like MyTool RAG) are enabled for a chat and the model uses default (prompt-based) function calling (not native), the backend loads the tools and logs that they will be “handled by tools handler”, but never calls chat_completion_tools_handler. As a result, the tool-calling prompt is not injected, the model/task model never gets a chance to emit a tool call, and the tool is never executed. No "Tool call (default mode)" or "Executing workspace tool" appears in logs, and the tool logic (e.g. RAG, API calls) does not run.
Root cause (code)
In backend/open_webui/utils/middleware.py, inside process_chat_payload, when tools_dict is non-empty:
If function_calling == "native": the code injects tools into form_data and sets metadata["tools"] so the model can return tool calls and the response handler runs them. Correct.
If function_calling is default: the code only logged and did not call chat_completion_tools_handler. The handler (which injects the tool prompt, calls the task model, parses the response, and executes the tool) was only called in the else branch when tools_dict was empty, so with tools loaded it was never run.
Fix (summary)
middleware.py Lines 2565-2579
```
            else:
                # Default (prompt-based) mode: must call the tools handler to inject the
                // tool-calling prompt and to parse the model response and execute tools.
                log.info(
                    "Chat tools (default/prompt): calling tools handler for %s tool(s): %s",
                    len(tools_dict),
                    list(tools_dict.keys()),
                )
                try:
                    form_data, flags = await chat_completion_tools_handler(
                        request, form_data, extra_params, user, models, tools_dict
                    )
                    sources.extend(flags.get("sources", []))
                except Exception as e:
                    log.exception(e)
```
In the same file, in the default branch of the if tools_dict: block (when function_calling != "native"), add a call to chat_completion_tools_handler and extend sources from its result, e.g.:
- Call: form_data, flags = await chat_completion_tools_handler(request, form_data, extra_params, user, models, tools_dict)
- Then: sources.extend(flags.get("sources", []))
- Wrap in try/except and log exceptions.
So the lines that fix the bug are those that invoke chat_completion_tools_handler in the default (prompt-based) branch when tools_dict is non-empty (in the current code, around lines 2565–2579 in middleware.py).
Originally created by @mlinares-tecnalia on GitHub (Feb 26, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/21901 ```` ### 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 have also searched in the CLOSED issues AND CLOSED discussions and found no related items (your issue might already be addressed on the development branch!). - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.8.5 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 22.04 ### Browser (if applicable) _No response_ ### 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 With a workspace tool enabled for the chat and the model in default function-calling mode: - The backend should call chat_completion_tools_handler so that: - The tool-calling prompt (and tool specs) is injected. - The task model (or equivalent path) can return a tool call (name + arguments). - The backend parses that response and executes the workspace tool (e.g. get_context_from_tecnalia). - Logs should show: Tool call (default mode): name=... in_tools=True and Executing workspace tool: ..., followed by the tool’s own logs (e.g. MyTool RAG steps). - The tool’s side effects (RAG query, citations, etc.) should occur and the final answer can use the tool result. ### Actual Behavior With a workspace tool enabled and the model in default function-calling mode: - Tools are loaded: logs show e.g. Chat tools loaded: 1 workspace tool(s) -> ['get_context_from_tecnalia'] and Chat tools (default/prompt): 1 tool(s) will be handled by tools handler. - But chat_completion_tools_handler is never invoked: the code only logs and returns; it does not inject the tool prompt or run the tool. - There are no log lines for "Tool call (default mode)" or "Executing workspace tool". - The workspace tool code (e.g. MyTool ) never runs; no RAG call, no citations, no tool result in the conversation. ### Steps to Reproduce 1. Environment - Open WebUI (version where the bug existed; fix is in backend/open_webui/utils/middleware.py). - Backend run via Docker/Compose or local run; no special env vars required for this bug. - One workspace tool installed (e.g. MyTool RAG) and visible under Workspace → Tools. 2. Model - Use a model that uses default function calling (e.g. Qwen3-32B, or any model not set to “Native” in Admin → Settings → Models → Function Calling). Ensure the model has access to the workspace tool (e.g. tool enabled for that model or for the chat). 3. Chat - Create a new chat. - Select the model above. - Enable the workspace tool for this chat (e.g. ➕ → select “MyTool RAG” or the relevant tool). 4. User action - Send a message that should trigger the tool (e.g. “What do you know about Tecnalia?” or “Search for projects about X” so the task model would choose to call the tool). 5. Observe - Expected: Tool runs (e.g. MyTool queries RAG, returns context/citations), and logs show Tool call (default mode): name=get_context_from_tecnalia in_tools=True and Executing workspace tool: get_context_from_tecnalia plus tool-specific logs. - Actual (before fix): Tool does not run; no “Tool call (default mode)” or “Executing workspace tool” in logs; only “Chat tools (default/prompt): … will be handled by tools handler” and then normal chat completion without tool execution. ### Logs & Screenshots 2026-02-26T11:43:04.639272098Z 2026-02-26 12:43:04.638 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 200 2026-02-26T11:43:04.661293977Z 2026-02-26 12:43:04.661 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 200 2026-02-26T11:43:06.740250977Z 2026-02-26 12:43:06.739 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/tools/ HTTP/1.1" 200 2026-02-26T11:43:08.514841064Z 2026-02-26 12:43:08.514 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 304 2026-02-26T11:43:09.092512135Z 2026-02-26 12:43:09.092 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 200 2026-02-26T11:43:09.990089232Z 2026-02-26 12:43:09.989 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 304 2026-02-26T11:43:10.058351038Z 2026-02-26 12:43:10.058 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 304 2026-02-26T11:43:13.515415314Z 2026-02-26 12:43:13.515 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/7bad7aa5-3cf0-4466-a7c4-0860021a923d HTTP/1.1" 200 2026-02-26T11:43:15.217970487Z 2026-02-26 12:43:15.217 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 304 2026-02-26T11:43:19.777924297Z 2026-02-26 12:43:19.777 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 200 2026-02-26T11:43:25.355511062Z 2026-02-26 12:43:25.354 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 200 2026-02-26T11:43:29.010907526Z 2026-02-26 12:43:29.010 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "POST /api/v1/chats/new HTTP/1.1" 200 2026-02-26T11:43:29.038626930Z 2026-02-26 12:43:29.038 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/tools/ HTTP/1.1" 200 2026-02-26T11:43:29.071493935Z 2026-02-26 12:43:29.071 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 2026-02-26T11:43:29.116171580Z 2026-02-26 12:43:29.115 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "POST /api/v1/chats/55e13486-f6a3-44c7-a8b0-6309509fcf80 HTTP/1.1" 200 2026-02-26T11:43:29.148716673Z 2026-02-26 12:43:29.148 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 2026-02-26T11:43:29.152106035Z 2026-02-26 12:43:29.151 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 304 2026-02-26T11:43:29.211771500Z 2026-02-26 12:43:29.211 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "POST /api/chat/completions HTTP/1.1" 200 2026-02-26T11:43:29.247434505Z 2026-02-26 12:43:29.247 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 2026-02-26T11:43:30.871058263Z 2026-02-26 12:43:30.870 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /_app/version.json HTTP/1.1" 200 2026-02-26T11:43:32.201734680Z 2026-02-26 12:43:32.200 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/55e13486-f6a3-44c7-a8b0-6309509fcf80 HTTP/1.1" 200 2026-02-26T11:43:32.399539797Z 2026-02-26 12:43:32.399 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "POST /api/v1/chats/7ad6b1ee-d895-4a47-9e2a-f415cb1eba2e HTTP/1.1" 200 2026-02-26T11:43:32.732243155Z 2026-02-26 12:43:32.731 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 2026-02-26T11:43:32.993766415Z 2026-02-26 12:43:32.993 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "POST /api/chat/completions HTTP/1.1" 200 2026-02-26T11:43:33.034456939Z 2026-02-26 12:43:33.034 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 192.168.x.x:0 - "GET /api/v1/chats/?page=1 HTTP/1.1" 200 ### Additional Information When workspace tools (e.g. custom Python tools like MyTool RAG) are enabled for a chat and the model uses default (prompt-based) function calling (not native), the backend loads the tools and logs that they will be “handled by tools handler”, but never calls chat_completion_tools_handler. As a result, the tool-calling prompt is not injected, the model/task model never gets a chance to emit a tool call, and the tool is never executed. No "Tool call (default mode)" or "Executing workspace tool" appears in logs, and the tool logic (e.g. RAG, API calls) does not run. Root cause (code) In backend/open_webui/utils/middleware.py, inside process_chat_payload, when tools_dict is non-empty: If function_calling == "native": the code injects tools into form_data and sets metadata["tools"] so the model can return tool calls and the response handler runs them. Correct. If function_calling is default: the code only logged and did not call chat_completion_tools_handler. The handler (which injects the tool prompt, calls the task model, parses the response, and executes the tool) was only called in the else branch when tools_dict was empty, so with tools loaded it was never run. Fix (summary) middleware.py Lines 2565-2579 ``` else: # Default (prompt-based) mode: must call the tools handler to inject the // tool-calling prompt and to parse the model response and execute tools. log.info( "Chat tools (default/prompt): calling tools handler for %s tool(s): %s", len(tools_dict), list(tools_dict.keys()), ) try: form_data, flags = await chat_completion_tools_handler( request, form_data, extra_params, user, models, tools_dict ) sources.extend(flags.get("sources", [])) except Exception as e: log.exception(e) ``` In the same file, in the default branch of the if tools_dict: block (when function_calling != "native"), add a call to chat_completion_tools_handler and extend sources from its result, e.g.: - Call: form_data, flags = await chat_completion_tools_handler(request, form_data, extra_params, user, models, tools_dict) - Then: sources.extend(flags.get("sources", [])) - Wrap in try/except and log exceptions. So the lines that fix the bug are those that invoke chat_completion_tools_handler in the default (prompt-based) branch when tools_dict is non-empty (in the current code, around lines 2565–2579 in middleware.py). ````
GiteaMirror added the bug label 2026-05-05 22:46:20 -05:00
GiteaMirror commented 2026-05-05 22:46:23 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Feb 26, 2026):

You're contradicting yourself in your explanation

You say to put the tool calling mode to native but in subsequent bullet points you say you expect the task model to handle the tool call. That's exactly not what's supposed to happen.

Can't reproduce

<!-- gh-comment-id:3966147409 --> @Classic298 commented on GitHub (Feb 26, 2026): You're contradicting yourself in your explanation You say to put the tool calling mode to native but in subsequent bullet points you say you expect the task model to handle the tool call. That's exactly not what's supposed to happen. Can't reproduce
GiteaMirror commented 2026-05-05 22:46:24 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Feb 26, 2026):

also probably duplicate if the issue is that tools dont execute. search for existing (closed) issues. this is fixed in dev

<!-- gh-comment-id:3966166226 --> @Classic298 commented on GitHub (Feb 26, 2026): also probably duplicate if the issue is that tools dont execute. search for existing (closed) issues. this is fixed in dev
GiteaMirror commented 2026-05-05 22:46:25 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Feb 26, 2026):

https://github.com/open-webui/open-webui/issues/21818

<!-- gh-comment-id:3966180784 --> @Classic298 commented on GitHub (Feb 26, 2026): https://github.com/open-webui/open-webui/issues/21818
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 bug
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#58274
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?