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 #20565] issue: [Bug] AttributeError: 'NoneType' object has no attribute 'get' in process_chat when model capabilities are None #19226

New Issue
Closed
opened 2026-04-20 01:35:14 -05:00 by GiteaMirror · 16 comments
GiteaMirror commented 2026-04-20 01:35:14 -05:00
Owner
Copy Link

Originally created by @a328929 on GitHub (Jan 11, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/20565

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

0.7.2

Ollama Version (if applicable)

No response

Operating System

Ubuntu 24.04

Browser (if applicable)

Chrome 100.0

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

The application should gracefully handle models with missing or null metadata (specifically the capabilities field). Instead of throwing an AttributeError, the system should default to an empty configuration (e.g., treating capabilities as {}) and proceed with the chat session normally.

Actual Behavior

Actual Behavior
When attempting to start a new chat session with a specific model (e.g., XiaomiMiMo/MiMo-V2-Flash), the request fails and the chat does not initialize. The backend logs indicate an AttributeError: 'NoneType' object has no attribute 'get', which occurs because the model's metadata capabilities field is set to None instead of a dictionary.

Steps to Reproduce

  1. Prerequisite (Model State):
    Ensure there is a model registered in the system (often imported via an external OpenAI-compatible connection) where the meta information is incomplete. Specifically, the capabilities field in the model's metadata must be None (null), rather than an empty dictionary {}.

    • Context from my logs: The model XiaomiMiMo/MiMo-V2-Flash had the following metadata structure: 'meta': {'description': None, 'capabilities': None}.

  2. Environment Configuration:
    Set the environment variable GLOBAL_LOG_LEVEL to DEBUG in your Docker container or .env file to ensure the traceback and payload details are visible in the logs.

  3. Navigate to Chat:
    Open the Open WebUI main interface and start a New Chat.

  4. Select the Model:
    From the model selector dropdown, choose the specific model identified in Step 1 (the one with capabilities: None).

  5. Trigger the Error:
    Type any message into the chat input (e.g., "Hello") and press Send.

  6. Observe the Failure:

    • UI: The chat will fail to initialize or respond.
    • Logs: Check the backend logs. You will observe that the process_chat function fails when attempting to access .get() on the capabilities object.
    • Specific Log Error: DEBUG | open_webui.main:process_chat:1746 - Error processing chat payload: 'NoneType' object has no attribute 'get'

Logs & Screenshots

Backend Logs (Docker):

# 1. Debug mode confirmed
2026-01-11 03:49:23.054 | INFO     | open_webui.utils.logger:start_logger:166 - GLOBAL_LOG_LEVEL: DEBUG

# 2. The payload showing the problematic 'meta' field (capabilities is None)
2026-01-11 03:50:36.319 | DEBUG    | open_webui.utils.middleware:process_chat_payload:1408 - form_data: {
  ...
  'model': {
    'id': 'XiaomiMiMo/MiMo-V2-Flash',
    ...
    'info': {
      ...
      'meta': {'description': None, 'capabilities': None},
      ...
    }
  }
  ...
}

# 3. The actual crash resulting from the NoneType
2026-01-11 03:50:36.326 | DEBUG    | open_webui.main:process_chat:1746 - Error processing chat payload: 'NoneType' object has no attribute 'get'


### Additional Information

### Environment Details
* **Open WebUI Version:** v0.7.2
* **Deployment:** Docker (via 1Panel)
* **Browser:** Chrome / Edge (Standard Web Browser)

### Log Analysis & Context
The issue was identified by enabling `GLOBAL_LOG_LEVEL=DEBUG`. The logs explicitly show the model metadata payload triggering the error.

**1. problematic Payload (before error):**
In `process_chat_payload`, the model object contains:
```json
'meta': {'description': None, 'capabilities': None}
Note: capabilities is None instead of the expected dictionary {}.
​2. Error Trace:
DEBUG | open_webui.main:process_chat:1746 - Error processing chat payload: 'NoneType' object has no attribute 'get'
Possible Cause
​It appears the backend logic assumes model.info.meta.capabilities is always a dictionary. When an external model provider (or a specific model configuration like XiaomiMiMo/MiMo-V2-Flash in my case) returns None for capabilities, the code attempts capabilities.get(...) without a prior null check, causing the crash.
​Confirmed Workaround
​Manually editing the model in the WebUI Admin Panel and clicking "Save" initializes the capabilities field to {}, which resolves the crash immediately.
Originally created by @a328929 on GitHub (Jan 11, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/20565 ### 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 0.7.2 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 24.04 ### Browser (if applicable) Chrome 100.0 ### 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 The application should gracefully handle models with missing or null metadata (specifically the capabilities field). Instead of throwing an AttributeError, the system should default to an empty configuration (e.g., treating capabilities as {}) and proceed with the chat session normally. ### Actual Behavior Actual Behavior When attempting to start a new chat session with a specific model (e.g., XiaomiMiMo/MiMo-V2-Flash), the request fails and the chat does not initialize. The backend logs indicate an AttributeError: 'NoneType' object has no attribute 'get', which occurs because the model's metadata capabilities field is set to None instead of a dictionary. ### Steps to Reproduce 1. **Prerequisite (Model State)**: Ensure there is a model registered in the system (often imported via an external OpenAI-compatible connection) where the `meta` information is incomplete. Specifically, the `capabilities` field in the model's metadata must be `None` (null), rather than an empty dictionary `{}`. * *Context from my logs*: The model `XiaomiMiMo/MiMo-V2-Flash` had the following metadata structure: `'meta': {'description': None, 'capabilities': None}`. 2. **Environment Configuration**: Set the environment variable `GLOBAL_LOG_LEVEL` to `DEBUG` in your Docker container or `.env` file to ensure the traceback and payload details are visible in the logs. 3. **Navigate to Chat**: Open the Open WebUI main interface and start a **New Chat**. 4. **Select the Model**: From the model selector dropdown, choose the specific model identified in Step 1 (the one with `capabilities: None`). 5. **Trigger the Error**: Type any message into the chat input (e.g., "Hello") and press **Send**. 6. **Observe the Failure**: * **UI**: The chat will fail to initialize or respond. * **Logs**: Check the backend logs. You will observe that the `process_chat` function fails when attempting to access `.get()` on the `capabilities` object. * *Specific Log Error*: `DEBUG | open_webui.main:process_chat:1746 - Error processing chat payload: 'NoneType' object has no attribute 'get'` ### Logs & Screenshots **Backend Logs (Docker):** ```text # 1. Debug mode confirmed 2026-01-11 03:49:23.054 | INFO | open_webui.utils.logger:start_logger:166 - GLOBAL_LOG_LEVEL: DEBUG # 2. The payload showing the problematic 'meta' field (capabilities is None) 2026-01-11 03:50:36.319 | DEBUG | open_webui.utils.middleware:process_chat_payload:1408 - form_data: { ... 'model': { 'id': 'XiaomiMiMo/MiMo-V2-Flash', ... 'info': { ... 'meta': {'description': None, 'capabilities': None}, ... } } ... } # 3. The actual crash resulting from the NoneType 2026-01-11 03:50:36.326 | DEBUG | open_webui.main:process_chat:1746 - Error processing chat payload: 'NoneType' object has no attribute 'get' ### Additional Information ### Environment Details * **Open WebUI Version:** v0.7.2 * **Deployment:** Docker (via 1Panel) * **Browser:** Chrome / Edge (Standard Web Browser) ### Log Analysis & Context The issue was identified by enabling `GLOBAL_LOG_LEVEL=DEBUG`. The logs explicitly show the model metadata payload triggering the error. **1. problematic Payload (before error):** In `process_chat_payload`, the model object contains: ```json 'meta': {'description': None, 'capabilities': None} Note: capabilities is None instead of the expected dictionary {}. ​2. Error Trace: DEBUG | open_webui.main:process_chat:1746 - Error processing chat payload: 'NoneType' object has no attribute 'get' Possible Cause ​It appears the backend logic assumes model.info.meta.capabilities is always a dictionary. When an external model provider (or a specific model configuration like XiaomiMiMo/MiMo-V2-Flash in my case) returns None for capabilities, the code attempts capabilities.get(...) without a prior null check, causing the crash. ​Confirmed Workaround ​Manually editing the model in the WebUI Admin Panel and clicking "Save" initializes the capabilities field to {}, which resolves the crash immediately.
GiteaMirror added the bug label 2026-04-20 01:35:14 -05:00
GiteaMirror commented 2026-04-20 01:35:16 -05:00
Author
Owner
Copy Link

@karoldydo commented on GitHub (Jan 11, 2026):

Same for me, similar setup.

image

image

<!-- gh-comment-id:3734455061 --> @karoldydo commented on GitHub (Jan 11, 2026): Same for me, similar setup. ![image](https://github.com/user-attachments/assets/e213183e-4769-4ed5-afa1-74da0cfe4a6e) ![image](https://github.com/user-attachments/assets/8c122b64-0039-4d8c-927c-185c887ff429)
GiteaMirror commented 2026-04-20 01:35:17 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 11, 2026):

delete your cache / force reload the page

<!-- gh-comment-id:3734478444 --> @Classic298 commented on GitHub (Jan 11, 2026): delete your cache / force reload the page
GiteaMirror commented 2026-04-20 01:35:19 -05:00
Author
Owner
Copy Link

@karoldydo commented on GitHub (Jan 11, 2026):

delete your cache / force reload the page

It's not a browser problem, I was trying on different browser even in private mode - same results.

<!-- gh-comment-id:3735342461 --> @karoldydo commented on GitHub (Jan 11, 2026): > delete your cache / force reload the page It's not a browser problem, I was trying on different browser even in private mode - same results.
GiteaMirror commented 2026-04-20 01:35:19 -05:00
Author
Owner
Copy Link

@karoldydo commented on GitHub (Jan 11, 2026):

I found a workaround that works for me:

  1. Go to Settings.
  2. Select Models.
  3. Choose the model that isn’t working (in my case, ministral-3:8b) and click it to open its details/settings.
  4. Don’t change anything - just click Save & Update at the bottom.
  5. Go back to your chat and try it out. Say hello! 🙂

I hope this helps you as well.

Best,
Karol

<!-- gh-comment-id:3735899088 --> @karoldydo commented on GitHub (Jan 11, 2026): I found a workaround that works for me: 1. Go to **Settings**. 2. Select **Models**. 3. Choose the model that isn’t working (in my case, ministral-3:8b) and click it to open its details/settings. 4. Don’t change anything - just click **Save & Update** at the bottom. 5. Go back to your chat and try it out. Say hello! 🙂 I hope this helps you as well. Best, Karol
GiteaMirror commented 2026-04-20 01:35:20 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 11, 2026):

thanks for sharing! will add that as troubleshooting steps to the docs as well. can anyone else confirm this works for them? We haven't really had issues like these internally nor from other users reporting this

<!-- gh-comment-id:3735938089 --> @Classic298 commented on GitHub (Jan 11, 2026): thanks for sharing! will add that as troubleshooting steps to the docs as well. can anyone else confirm this works for them? We haven't really had issues like these internally nor from other users reporting this
GiteaMirror commented 2026-04-20 01:35:20 -05:00
Author
Owner
Copy Link

@a328929 commented on GitHub (Jan 12, 2026):

I've dug a bit deeper into the code logic.

The root cause is indeed that model_info['meta']['capabilities'] is returning None for these specific models, and the backend code doesn't guard against this before calling .get().

Here is a suggested fix that would make the backend more robust. In open_webui/main.py (inside the process_chat function), we should sanitize the capabilities dictionary before using it.

Suggested Code Change:

# Current problematic logic (conceptually):
# if model_info['meta']['capabilities'].get('vision'): ...

# Recommended fix:
# Ensure capabilities is at least an empty dict if None
capabilities = model_info.get('meta', {}).get('capabilities') or {}

# Now we can safely check for features without crashing
if capabilities.get('vision'):
    # ... handle vision ...
This simple check prevents the AttributeError: 'NoneType' object has no attribute 'get' crash and allows the chat to proceed with default (disabled) capabilities for such models.
<!-- gh-comment-id:3736831598 --> @a328929 commented on GitHub (Jan 12, 2026): I've dug a bit deeper into the code logic. The root cause is indeed that `model_info['meta']['capabilities']` is returning `None` for these specific models, and the backend code doesn't guard against this before calling `.get()`. Here is a suggested fix that would make the backend more robust. In `open_webui/main.py` (inside the `process_chat` function), we should sanitize the capabilities dictionary before using it. **Suggested Code Change:** ```python # Current problematic logic (conceptually): # if model_info['meta']['capabilities'].get('vision'): ... # Recommended fix: # Ensure capabilities is at least an empty dict if None capabilities = model_info.get('meta', {}).get('capabilities') or {} # Now we can safely check for features without crashing if capabilities.get('vision'): # ... handle vision ... This simple check prevents the AttributeError: 'NoneType' object has no attribute 'get' crash and allows the chat to proceed with default (disabled) capabilities for such models.
GiteaMirror commented 2026-04-20 01:35:21 -05:00
Author
Owner
Copy Link

@AndreasUpb commented on GitHub (Jan 15, 2026):

I re-saved the models like described in the workaround, but some users reported afterwards the issue again

Image
<!-- gh-comment-id:3755030239 --> @AndreasUpb commented on GitHub (Jan 15, 2026): I re-saved the models like described in the workaround, but some users reported afterwards the issue again <img width="1100" height="198" alt="Image" src="https://github.com/user-attachments/assets/f6bf627f-71c6-4b4b-ac82-12bfe233f5b2" />
GiteaMirror commented 2026-04-20 01:35:21 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 15, 2026):

@AndreasUpb deleted cache?

<!-- gh-comment-id:3755123432 --> @Classic298 commented on GitHub (Jan 15, 2026): @AndreasUpb deleted cache?
GiteaMirror commented 2026-04-20 01:35:22 -05:00
Author
Owner
Copy Link

@aq2kx commented on GitHub (Jan 15, 2026):

Same issue here

<!-- gh-comment-id:3755298298 --> @aq2kx commented on GitHub (Jan 15, 2026): Same issue here
GiteaMirror commented 2026-04-20 01:35:22 -05:00
Author
Owner
Copy Link

@AndreasUpb commented on GitHub (Jan 15, 2026):

@AndreasUpb deleted cache?

Good hint, thank you. Disabled model cache; Saved; Activated model list again; Saved.
Will report if users still run in this problem

<!-- gh-comment-id:3755314564 --> @AndreasUpb commented on GitHub (Jan 15, 2026): > [@AndreasUpb](https://github.com/AndreasUpb) deleted cache? Good hint, thank you. Disabled model cache; Saved; Activated model list again; Saved. Will report if users still run in this problem
GiteaMirror commented 2026-04-20 01:35:22 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 15, 2026):

i meant browser cache but yeah

<!-- gh-comment-id:3755332413 --> @Classic298 commented on GitHub (Jan 15, 2026): i meant browser cache but yeah
GiteaMirror commented 2026-04-20 01:35:23 -05:00
Author
Owner
Copy Link

@nielskorte commented on GitHub (Jan 20, 2026):

Had the same issue! Please fix it. Going to the models and just saving it again worked as a fix for now.

Image
<!-- gh-comment-id:3772563823 --> @nielskorte commented on GitHub (Jan 20, 2026): Had the same issue! Please fix it. Going to the models and just saving it again worked as a fix for now. <img width="1734" height="386" alt="Image" src="https://github.com/user-attachments/assets/d7ad3102-619f-4878-9f42-46594123fdc8" />
GiteaMirror commented 2026-04-20 01:35:23 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Jan 20, 2026):

A PR is already pending as you can see above... @nielskorte

<!-- gh-comment-id:3772624148 --> @Classic298 commented on GitHub (Jan 20, 2026): A PR is already pending as you can see above... @nielskorte
GiteaMirror commented 2026-04-20 01:35:23 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Jan 22, 2026):

Should be fixed in dev, testing wanted here!

<!-- gh-comment-id:3783818278 --> @tjbck commented on GitHub (Jan 22, 2026): Should be fixed in dev, testing wanted here!
GiteaMirror commented 2026-04-20 01:35:24 -05:00
Author
Owner
Copy Link

@flyingbrike commented on GitHub (Jan 27, 2026):

I found a workaround that works for me:

  1. Go to Settings.
  2. Select Models.
  3. Choose the model that isn’t working (in my case, ministral-3:8b) and click it to open its details/settings.
  4. Don’t change anything - just click Save & Update at the bottom.
  5. Go back to your chat and try it out. Say hello! 🙂

I hope this helps you as well.

Best, Karol

This worked for me. Thx

<!-- gh-comment-id:3804243375 --> @flyingbrike commented on GitHub (Jan 27, 2026): > I found a workaround that works for me: > > 1. Go to **Settings**. > 2. Select **Models**. > 3. Choose the model that isn’t working (in my case, ministral-3:8b) and click it to open its details/settings. > 4. Don’t change anything - just click **Save & Update** at the bottom. > 5. Go back to your chat and try it out. Say hello! 🙂 > > I hope this helps you as well. > > Best, Karol This worked for me. Thx
GiteaMirror commented 2026-04-20 01:35:24 -05:00
Author
Owner
Copy Link

@tahaipek commented on GitHub (Feb 1, 2026):

I found a workaround that works for me:

  1. Go to Settings.
  2. Select Models.
  3. Choose the model that isn’t working (in my case, ministral-3:8b) and click it to open its details/settings.
  4. Don’t change anything - just click Save & Update at the bottom.
  5. Go back to your chat and try it out. Say hello! 🙂

I hope this helps you as well.

Best,
Karol

Thanks! This workaround solved the issue for me 👍
Editing the model in Admin and hitting Save fixed the NoneType.get error instantly.

<!-- gh-comment-id:3832037211 --> @tahaipek commented on GitHub (Feb 1, 2026): > I found a workaround that works for me: > > 1. Go to **Settings**. > 2. Select **Models**. > 3. Choose the model that isn’t working (in my case, ministral-3:8b) and click it to open its details/settings. > 4. Don’t change anything - just click **Save & Update** at the bottom. > 5. Go back to your chat and try it out. Say hello! 🙂 > > I hope this helps you as well. > > Best, > Karol Thanks! This workaround solved the issue for me 👍 Editing the model in Admin and hitting Save fixed the `NoneType.get` error instantly.
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#19226
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?