[GH-ISSUE #23943] issue: create_automation builtin tool returns "Could not detect current model", model_id missing from metadata in chat.py path #35650

Closed
opened 2026-04-25 09:49:38 -05:00 by GiteaMirror · 5 comments
Owner

Originally created by @malte325 on GitHub (Apr 21, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23943

Check Existing Issues

  • I have searched for any existing and/or related issues.
  • I have searched for any existing and/or related discussions.
  • 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!).
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.9.1

Ollama Version (if applicable)

No response

Operating System

Ubuntu 24.04.4 LTS

Browser (if applicable)

chrome

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

create_automation should succeed and return the created automation (id, name, next runs), using the model currently selected in the chat.

Actual Behavior

The tool always fails with "Could not detect current model". No error is logged server-side (the tool swallows its own early-return, no log.exception is hit), which made this hard to diagnose initially.

Steps to Reproduce

  1. Install Open WebUI v0.9.1 with an OpenAI connection (Chat Completions or Responses API — both reproduce it).
  2. Enable Automations: ENABLE_AUTOMATIONS=True, grant the user the automations permission, ensure builtinTools.automations is enabled for the model.
  3. Set the chat's Function Calling to native (Chat Controls → Advanced Params → Function Calling → Native).
  4. In a chat with e.g. gpt-4o, prompt something that triggers automation creation, for example:

    Erstelle mir eine Automation die jeden Werktag um 9:00 einen AI-News-Report schickt.

  5. The model emits a tool call to create_automation with a valid payload (name, prompt, RRULE).
  6. The tool returns: {"error": "Could not detect current model"}.

Logs & Screenshots

none

Additional Information

Where the error is raised

backend/open_webui/tools/builtin.py, lines 2571–2574 (v0.9.1):

# Always use the calling model for the automation
model_id = (__metadata__ or {}).get('model_id')
if not model_id:
    return json.dumps({'error': 'Could not detect current model'})

The tool expects __metadata__['model_id'] to be populated by the caller.

Where model_id should be populated

backend/open_webui/utils/middleware.py, inside process_chat_payload, lines 2529–2535:

metadata = {
    **metadata,
    'model_id': form_data.get('model'),
    'tool_ids': tool_ids,
    'terminal_id': terminal_id,
    'files': files,
}

This line is intended to enrich metadata with model_id before tools are resolved.

The actual bug: stale reference in extra_params

Earlier in the same function (lines 2272–2282), extra_params is built and binds a reference to the current metadata object:

extra_params = {
    '__event_emitter__': event_emitter,
    '__event_call__': event_caller,
    '__user__': user.model_dump() if isinstance(user, UserModel) else {},
    '__metadata__': metadata,                   # ← reference captured here
    '__oauth_token__': await get_system_oauth_token(request, user),
    '__request__': request,
    '__model__': model,
    '__chat_id__': metadata.get('chat_id'),
    '__message_id__': metadata.get('message_id'),
}

At line 2529, the statement

metadata = {**metadata, 'model_id': ..., ...}

does not mutate the existing dict — it constructs a new dict from the spread and rebinds the local name metadata to it. The dict still referenced by extra_params['__metadata__'] is the original one, which has no model_id key.

Later at line 2746, get_builtin_tools is invoked with extra_params as-is. The builtin tool wrapper in backend/open_webui/utils/tools.py (line 582) forwards extra_params.get('__metadata__') directly to each builtin function's __metadata__ parameter. Since that reference still points to the pre-enrichment dict, create_automation sees model_id = None and bails out.

No similar issue occurs for chat_id / message_id because those are set earlier (before the extra_params construction) and so are already present in the captured reference.

Proposed Fix

Either mutate in place instead of rebinding at line 2529:

metadata.update({
    'model_id': form_data.get('model'),
    'tool_ids': tool_ids,
    'terminal_id': terminal_id,
    'files': files,
})

Or, if the existing assignment style is preferred, update extra_params['__metadata__'] alongside it:

metadata = {**metadata, 'model_id': form_data.get('model'), ...}
form_data['metadata'] = metadata
extra_params['__metadata__'] = metadata   # keep extra_params in sync

T

Originally created by @malte325 on GitHub (Apr 21, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/23943 ### 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.9.1 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 24.04.4 LTS ### Browser (if applicable) chrome ### 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 `create_automation` should succeed and return the created automation (id, name, next runs), using the model currently selected in the chat. ### Actual Behavior The tool always fails with `"Could not detect current model"`. No error is logged server-side (the tool swallows its own early-return, no `log.exception` is hit), which made this hard to diagnose initially. ### Steps to Reproduce 1. Install Open WebUI v0.9.1 with an OpenAI connection (Chat Completions or Responses API — both reproduce it). 2. Enable Automations: `ENABLE_AUTOMATIONS=True`, grant the user the `automations` permission, ensure `builtinTools.automations` is enabled for the model. 3. Set the chat's Function Calling to `native` (Chat Controls → Advanced Params → Function Calling → Native). 4. In a chat with e.g. `gpt-4o`, prompt something that triggers automation creation, for example: > Erstelle mir eine Automation die jeden Werktag um 9:00 einen AI-News-Report schickt. 5. The model emits a tool call to `create_automation` with a valid payload (name, prompt, RRULE). 6. The tool returns: `{"error": "Could not detect current model"}`. ### Logs & Screenshots none ### Additional Information ### Where the error is raised `backend/open_webui/tools/builtin.py`, lines 2571–2574 (v0.9.1): ```python # Always use the calling model for the automation model_id = (__metadata__ or {}).get('model_id') if not model_id: return json.dumps({'error': 'Could not detect current model'}) ``` The tool expects `__metadata__['model_id']` to be populated by the caller. ### Where `model_id` *should* be populated `backend/open_webui/utils/middleware.py`, inside `process_chat_payload`, lines 2529–2535: ```python metadata = { **metadata, 'model_id': form_data.get('model'), 'tool_ids': tool_ids, 'terminal_id': terminal_id, 'files': files, } ``` This line is intended to enrich `metadata` with `model_id` before tools are resolved. ### The actual bug: stale reference in `extra_params` Earlier in the same function (lines 2272–2282), `extra_params` is built and binds a reference to the current `metadata` object: ```python extra_params = { '__event_emitter__': event_emitter, '__event_call__': event_caller, '__user__': user.model_dump() if isinstance(user, UserModel) else {}, '__metadata__': metadata, # ← reference captured here '__oauth_token__': await get_system_oauth_token(request, user), '__request__': request, '__model__': model, '__chat_id__': metadata.get('chat_id'), '__message_id__': metadata.get('message_id'), } ``` At line 2529, the statement ```python metadata = {**metadata, 'model_id': ..., ...} ``` does **not** mutate the existing dict — it constructs a new dict from the spread and rebinds the local name `metadata` to it. The dict still referenced by `extra_params['__metadata__']` is the original one, which has no `model_id` key. Later at line 2746, `get_builtin_tools` is invoked with `extra_params` as-is. The builtin tool wrapper in `backend/open_webui/utils/tools.py` (line 582) forwards `extra_params.get('__metadata__')` directly to each builtin function's `__metadata__` parameter. Since that reference still points to the pre-enrichment dict, `create_automation` sees `model_id = None` and bails out. No similar issue occurs for `chat_id` / `message_id` because those are set earlier (before the `extra_params` construction) and so are already present in the captured reference. ## Proposed Fix Either mutate in place instead of rebinding at line 2529: ```python metadata.update({ 'model_id': form_data.get('model'), 'tool_ids': tool_ids, 'terminal_id': terminal_id, 'files': files, }) ``` Or, if the existing assignment style is preferred, update `extra_params['__metadata__']` alongside it: ```python metadata = {**metadata, 'model_id': form_data.get('model'), ...} form_data['metadata'] = metadata extra_params['__metadata__'] = metadata # keep extra_params in sync ``` T
GiteaMirror added the bug label 2026-04-25 09:49:38 -05:00
Author
Owner

@Ra0k commented on GitHub (Apr 21, 2026):

Same!

<!-- gh-comment-id:4289805684 --> @Ra0k commented on GitHub (Apr 21, 2026): Same!
Author
Owner

@Classic298 commented on GitHub (Apr 21, 2026):

can repro

<!-- gh-comment-id:4290027815 --> @Classic298 commented on GitHub (Apr 21, 2026): can repro
Author
Owner

@bmc0923 commented on GitHub (Apr 21, 2026):

I have this same issue. Does it only occur for certain models or configurations? Is there anything I can do for the moment to mitigate this?

<!-- gh-comment-id:4292221720 --> @bmc0923 commented on GitHub (Apr 21, 2026): I have this same issue. Does it only occur for certain models or configurations? Is there anything I can do for the moment to mitigate this?
Author
Owner

@Classic298 commented on GitHub (Apr 21, 2026):

no just broken at the moment, you can disable the builtin automations tools inside the chat if you want - you can still create automations manually

<!-- gh-comment-id:4292241586 --> @Classic298 commented on GitHub (Apr 21, 2026): no just broken at the moment, you can disable the builtin automations tools inside the chat if you want - you can still create automations manually
Author
Owner

@tjbck commented on GitHub (Apr 24, 2026):

Addressed in dev.

<!-- gh-comment-id:4311246752 --> @tjbck commented on GitHub (Apr 24, 2026): Addressed in dev.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#35650