[GH-ISSUE #24157] issue: Chat stuck in infinite Loading when history.currentId points to a malformed provider response object after safety rejection #58880

New Issue

Open

opened 2026-05-06 00:19:52 -05:00 by GiteaMirror · 0 comments

GiteaMirror commented 2026-05-06 00:19:52 -05:00

Owner

Copy Link

Originally created by @mcxiaochenn on GitHub (Apr 26, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24157

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.2

Ollama Version (if applicable)

No response

Operating System

Debian 12

Browser (if applicable)

No response

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

A malformed or non-standard provider response should not permanently break an OpenWebUI chat.

If an upstream OpenAI-compatible provider returns a safety rejection, content filter response, or unsupported response shape, OpenWebUI should either:

1. Normalize it into a valid assistant message.
2. Store it as a recoverable error message.
3. Prevent it from being assigned as chat.history.currentId.
4. Show a clear UI error instead of infinite Loading.
5. Fall back to the last valid message node if history.currentId points to an invalid object.

At minimum, OpenWebUI should validate that the current message has a valid message schema before rendering it, including fields such as:

{
  "role": "assistant",
  "content": "...",
  "childrenIds": []
}

A single malformed provider response should not make the entire chat unusable.

Actual Behavior

One chat became permanently stuck on the Loading screen.

The backend endpoint still returned HTTP 200:

GET /api/v1/chats/c42c4393-0cec-46cc-8053-c06b21a53789
Status: 200 OK

The response body contained the chat data, but the frontend could not render the chat.

The browser console repeatedly showed warnings such as:

[tiptap warn]: Duplicate extension names found: ['codeBlock', 'bulletList', 'listItem', 'listKeymap', 'orderedList']. This can lead to issues.

and repeated performance warnings around:

ResponseMessage.svelte
Added non-passive event listener to a scroll-blocking 'wheel' event
Forced reflow while executing JavaScript took 50ms

These warnings appear to be secondary noise caused by repeated rendering attempts. The actual issue was a malformed message node inside chat.history.messages.

The problematic node was assigned as:

chat.history.currentId = ecb2c670-f1b7-46e0-a1ab-ee675dfe739a

But this object was not a valid OpenWebUI message. It contained fields like:

{
  "done": true,
  "content": "...The request was rejected because it was considered high risk",
  "output": [...],
  "usage": {...},
  "statusHistory": [...]
}

It was missing normal message fields such as:

role
parentId
childrenIds
timestamp

Browser-side validation showed:

missing_or_invalid_childrenIds
id: ecb2c670-f1b7-46e0-a1ab-ee675dfe739a
role: undefined
childrenIds: undefined
problem count: 1

No other message referenced this node through childrenIds, so it appeared to be an orphan malformed node. However, since history.currentId pointed to it, the chat page could not render and stayed in infinite Loading.

Steps to Reproduce

There are two related reproduction paths: the real-world provider-triggered path and an isolated malformed-chat-data path.

A. Real-world provider-triggered reproduction

1. Deploy OpenWebUI using Docker Compose.
2. Use SQLite as the OpenWebUI database.
3. Configure a third-party OpenAI-compatible provider.
   • In my case, the provider was Xiaomi MiMo API through an OpenAI-compatible endpoint.
4. Start a chat with that model.
5. Send a request that triggers the provider-side safety filter.
6. The provider returns a rejection message similar to:

The request was rejected because it was considered high risk

7. After this rejection, reload or reopen the affected chat.
8. The chat page shows infinite Loading.
9. The backend still returns HTTP 200 for:

GET /api/v1/chats/{chat_id}

10. Inspecting the returned chat JSON shows that chat.history.currentId points to a malformed object in chat.history.messages.

B. Isolated data-level reproduction

This is the minimal condition that appears to trigger the frontend issue:

1. Have a chat where chat.history.currentId points to a key in chat.history.messages.
2. Make that message object malformed, for example:

{
  "done": true,
  "content": "The request was rejected because it was considered high risk",
  "output": [],
  "usage": {},
  "statusHistory": []
}

3. Ensure this object does not contain:

role
childrenIds
parentId
timestamp

4. Open the chat in the browser.
5. The chat page gets stuck in Loading instead of showing a recoverable error.

Validation script used in browser console

const chatId = 'c42c4393-0cec-46cc-8053-c06b21a53789';

const data = await fetch(`/api/v1/chats/${chatId}`, {
  credentials: 'include',
  headers: { Accept: 'application/json' }
}).then(r => r.json());

const chat = data.chat ?? data;
const h = chat.history ?? {};
const messages = h.messages ?? {};

const problems = [];

if (!h.currentId) {
  problems.push({ type: 'missing_currentId' });
} else if (!messages[h.currentId]) {
  problems.push({ type: 'currentId_not_found', currentId: h.currentId });
}

for (const [id, m] of Object.entries(messages)) {
  if (!Array.isArray(m.childrenIds)) {
    problems.push({
      type: 'missing_or_invalid_childrenIds',
      id,
      role: m.role,
      childrenIds: m.childrenIds
    });
  }

  if (m.parentId && !messages[m.parentId]) {
    problems.push({
      type: 'parentId_not_found',
      id,
      role: m.role,
      parentId: m.parentId
    });
  }

  if (Array.isArray(m.childrenIds)) {
    for (const childId of m.childrenIds) {
      if (!messages[childId]) {
        problems.push({
          type: 'childId_not_found',
          id,
          role: m.role,
          childId
        });
      } else if (messages[childId].parentId !== id) {
        problems.push({
          type: 'child_parent_mismatch',
          parent: id,
          child: childId,
          childParentId: messages[childId].parentId
        });
      }
    }
  }
}

console.table(problems);
console.log('problem count:', problems.length);

The output was:

missing_or_invalid_childrenIds
id: ecb2c670-f1b7-46e0-a1ab-ee675dfe739a
role: undefined
childrenIds: undefined
problem count: 1

Logs & Screenshots

Browser console logs

The browser console repeatedly showed:

[tiptap warn]: Duplicate extension names found: ['codeBlock', 'bulletList', 'listItem', 'listKeymap', 'orderedList']. This can lead to issues.

Repeated rendering / performance warnings:

ResponseMessage.svelte:593 [Violation]
Added non-passive event listener to a scroll-blocking 'wheel' event.
Forced reflow while executing JavaScript took 50ms

API response check

The chat endpoint returned HTTP 200:

Request URL:
https://url/api/v1/chats/c42c4393-0cec-46cc-8053-c06b21a53789

Request Method:
GET

Status Code:
200 OK

But the frontend still showed infinite Loading.

Active task check

I also tried:

await fetch('/api/v1/tasks/active/chats', {
  credentials: 'include',
  headers: {
    Accept: 'application/json'
  }
}).then(r => r.json())

In my environment this returned HTML instead of JSON:

Unexpected token '<', "<!doctype "... is not valid JSON

Further inspection showed:

status: 200
content-type: text/html; charset=utf-8
<!doctype html>
<html lang="en">
...

So this endpoint was not useful in my current version/setup.

Unfinished message check

I checked whether any messages had done: false or pending status:

Object.entries(messages)
  .filter(([id, m]) => m.done === false || m.error || m.status === 'pending')

The result was:

unfinished: []

So this was not a normal unfinished-generation state.

Malformed node details

The problematic node was:

ecb2c670-f1b7-46e0-a1ab-ee675dfe739a

Its keys were:

done
content
output
usage
statusHistory

It did not contain:

role
parentId
childrenIds
timestamp

The content included:

The request was rejected because it was considered high risk

Docker logs

Relevant container logs around restart showed normal startup messages such as:

Loading WEBUI_SECRET_KEY from file, not provided as an environment variable.
Loading WEBUI_SECRET_KEY from .webui_secret_key
INFO  [alembic.runtime.migration] Context impl SQLiteImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
WARNING: CORS_ALLOW_ORIGIN IS SET TO '*' - NOT RECOMMENDED FOR PRODUCTION DEPLOYMENTS.

No clear backend exception was visible in the short log excerpt I checked.

Manual database repair output

I manually repaired the SQLite database by deleting the malformed orphan node and setting history.currentId to the last valid leaf message.

Repair output:

before currentId: ecb2c670-f1b7-46e0-a1ab-ee675dfe739a
before message count: 65
deleted bad node: ecb2c670-f1b7-46e0-a1ab-ee675dfe739a
after currentId: 35bfac66-bdbf-4147-ab58-04c4064daeef
after message count: 64
repair done

Additional Information

Root cause hypothesis

The immediate cause appears to be:

chat.history.currentId points to a malformed object that is not a valid OpenWebUI message.

The trigger was an upstream provider-side safety rejection:

The request was rejected because it was considered high risk

However, the safety rejection itself should not permanently break a chat. The more important issue is that the rejected provider response appears to have been saved into chat.history.messages without being normalized into OpenWebUI's expected message schema.

The malformed object looked more like a raw provider response or Responses-API-style object:

{
  "done": true,
  "content": "...",
  "output": [...],
  "usage": {...},
  "statusHistory": [...]
}

instead of a valid chat message object:

{
  "id": "...",
  "role": "assistant",
  "content": "...",
  "parentId": "...",
  "childrenIds": [],
  "timestamp": 1234567890
}

Why this matters

This issue significantly increases troubleshooting cost:

• The backend API returns HTTP 200.
• The UI only shows infinite Loading.
• Browser console warnings point to Tiptap and scroll listeners, which are misleading.
• The user has to inspect raw chat JSON.
• Recovery requires manual SQLite database editing.
• A single malformed provider response can make an entire chat unusable.
• Non-technical users may have no practical recovery path.

Suggested frontend safeguard

Before rendering the current message, OpenWebUI could validate the node:

const currentMessage = messages[currentId];

if (
  !currentMessage ||
  !currentMessage.role ||
  !Array.isArray(currentMessage.childrenIds)
) {
  // Show a recoverable error instead of infinite Loading.
  // Optionally fall back to the last valid leaf message.
}

The UI could show a message such as:

This chat contains an invalid message node and cannot render the selected branch.
You can switch to the last valid message or attempt automatic repair.

Suggested backend safeguard

Before saving a provider response into chat history, OpenWebUI could enforce a minimal message schema:

{
  id: string;
  role: "user" | "assistant" | "system";
  content: string;
  parentId: string | null;
  childrenIds: string[];
  timestamp?: number;
}

If an upstream response contains fields like:

done
output
usage
statusHistory

but does not contain role or childrenIds, it should not be inserted directly into history.messages.

Suggested repair behavior

OpenWebUI could provide an automatic safe repair mechanism:

1. Detect whether history.currentId exists.
2. Check whether history.messages[history.currentId] is a valid message object.
3. If invalid, search for the last valid leaf message.
4. Set history.currentId to that valid leaf message.
5. Preserve the malformed object for diagnostics if needed.
6. Surface a warning to the user or admin.

Related upstream provider behavior

The upstream provider in this case was Xiaomi MiMo API through an OpenAI-compatible endpoint.

I understand that the upstream provider should also return a valid OpenAI-compatible response for rejected requests. However, OpenWebUI can still protect users by validating message objects before saving them and by handling invalid currentId targets gracefully during rendering.

This would make OpenWebUI more robust when dealing with third-party OpenAI-compatible providers, gateways, proxies, and safety-filter rejection responses.

AI assistance disclosure

This issue was drafted with AI assistance based on a real debugging session, browser console output, OpenWebUI chat JSON inspection, and a manual SQLite repair process provided by the user.

AI assistance details:

AI provider: OpenAI
AI product: ChatGPT
Model: GPT-5.5 Thinking
Model type: reasoning-oriented large language model
Primary capabilities used: technical debugging, log analysis, JSON structure analysis, root-cause summarization, issue drafting
Knowledge cutoff: 2025-08
Generation date: 2026-04-26
Output language: English
User-provided evidence used: OpenWebUI console logs, malformed message object fields, currentId value, validation output, repair script output
Direct access to user's server: No
Direct modification of user's environment: No
Official statement from OpenWebUI: No
Official statement from Xiaomi MiMo: No

Model parameter and performance disclosure:

Exact inference parameters: Not exposed to the end user. Values such as temperature, top_p, frequency_penalty, presence_penalty, seed, and internal routing parameters are not available.
Context capability: The model supports long-context technical reasoning and multi-turn debugging, but an exact publicly disclosed context window value was not available in this session.
Performance profile: Optimized for multi-step reasoning, technical analysis, code and log interpretation, structured writing, and root-cause explanation.
Limitations: The issue text is based on user-provided evidence and observable behavior. It should not be treated as an official RCA from OpenWebUI or Xiaomi MiMo. The exact upstream API behavior should still be verified by maintainers using server-side logs and reproducible test cases.

Originally created by @mcxiaochenn on GitHub (Apr 26, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24157 ### 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.2 ### Ollama Version (if applicable) _No response_ ### Operating System Debian 12 ### 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 A malformed or non-standard provider response should not permanently break an OpenWebUI chat. If an upstream OpenAI-compatible provider returns a safety rejection, content filter response, or unsupported response shape, OpenWebUI should either: 1. Normalize it into a valid assistant message. 2. Store it as a recoverable error message. 3. Prevent it from being assigned as `chat.history.currentId`. 4. Show a clear UI error instead of infinite Loading. 5. Fall back to the last valid message node if `history.currentId` points to an invalid object. At minimum, OpenWebUI should validate that the current message has a valid message schema before rendering it, including fields such as: ```json { "role": "assistant", "content": "...", "childrenIds": [] } ```` A single malformed provider response should not make the entire chat unusable. ### Actual Behavior One chat became permanently stuck on the Loading screen. The backend endpoint still returned HTTP 200: ```text GET /api/v1/chats/c42c4393-0cec-46cc-8053-c06b21a53789 Status: 200 OK ```` The response body contained the chat data, but the frontend could not render the chat. The browser console repeatedly showed warnings such as: ```text [tiptap warn]: Duplicate extension names found: ['codeBlock', 'bulletList', 'listItem', 'listKeymap', 'orderedList']. This can lead to issues. ``` and repeated performance warnings around: ```text ResponseMessage.svelte Added non-passive event listener to a scroll-blocking 'wheel' event Forced reflow while executing JavaScript took 50ms ``` These warnings appear to be secondary noise caused by repeated rendering attempts. The actual issue was a malformed message node inside `chat.history.messages`. The problematic node was assigned as: ```text chat.history.currentId = ecb2c670-f1b7-46e0-a1ab-ee675dfe739a ``` But this object was not a valid OpenWebUI message. It contained fields like: ```json { "done": true, "content": "...The request was rejected because it was considered high risk", "output": [...], "usage": {...}, "statusHistory": [...] } ``` It was missing normal message fields such as: ```text role parentId childrenIds timestamp ``` Browser-side validation showed: ```text missing_or_invalid_childrenIds id: ecb2c670-f1b7-46e0-a1ab-ee675dfe739a role: undefined childrenIds: undefined problem count: 1 ``` No other message referenced this node through `childrenIds`, so it appeared to be an orphan malformed node. However, since `history.currentId` pointed to it, the chat page could not render and stayed in infinite Loading. ### Steps to Reproduce There are two related reproduction paths: the real-world provider-triggered path and an isolated malformed-chat-data path. ### A. Real-world provider-triggered reproduction 1. Deploy OpenWebUI using Docker Compose. 2. Use SQLite as the OpenWebUI database. 3. Configure a third-party OpenAI-compatible provider. - In my case, the provider was Xiaomi MiMo API through an OpenAI-compatible endpoint. 4. Start a chat with that model. 5. Send a request that triggers the provider-side safety filter. 6. The provider returns a rejection message similar to: ```text The request was rejected because it was considered high risk ```` 7. After this rejection, reload or reopen the affected chat. 8. The chat page shows infinite Loading. 9. The backend still returns HTTP 200 for: ```text GET /api/v1/chats/{chat_id} ``` 10. Inspecting the returned chat JSON shows that `chat.history.currentId` points to a malformed object in `chat.history.messages`. ### B. Isolated data-level reproduction This is the minimal condition that appears to trigger the frontend issue: 1. Have a chat where `chat.history.currentId` points to a key in `chat.history.messages`. 2. Make that message object malformed, for example: ```json { "done": true, "content": "The request was rejected because it was considered high risk", "output": [], "usage": {}, "statusHistory": [] } ``` 3. Ensure this object does not contain: ```text role childrenIds parentId timestamp ``` 4. Open the chat in the browser. 5. The chat page gets stuck in Loading instead of showing a recoverable error. ### Validation script used in browser console ```js const chatId = 'c42c4393-0cec-46cc-8053-c06b21a53789'; const data = await fetch(`/api/v1/chats/${chatId}`, { credentials: 'include', headers: { Accept: 'application/json' } }).then(r => r.json()); const chat = data.chat ?? data; const h = chat.history ?? {}; const messages = h.messages ?? {}; const problems = []; if (!h.currentId) { problems.push({ type: 'missing_currentId' }); } else if (!messages[h.currentId]) { problems.push({ type: 'currentId_not_found', currentId: h.currentId }); } for (const [id, m] of Object.entries(messages)) { if (!Array.isArray(m.childrenIds)) { problems.push({ type: 'missing_or_invalid_childrenIds', id, role: m.role, childrenIds: m.childrenIds }); } if (m.parentId && !messages[m.parentId]) { problems.push({ type: 'parentId_not_found', id, role: m.role, parentId: m.parentId }); } if (Array.isArray(m.childrenIds)) { for (const childId of m.childrenIds) { if (!messages[childId]) { problems.push({ type: 'childId_not_found', id, role: m.role, childId }); } else if (messages[childId].parentId !== id) { problems.push({ type: 'child_parent_mismatch', parent: id, child: childId, childParentId: messages[childId].parentId }); } } } } console.table(problems); console.log('problem count:', problems.length); ``` The output was: ```text missing_or_invalid_childrenIds id: ecb2c670-f1b7-46e0-a1ab-ee675dfe739a role: undefined childrenIds: undefined problem count: 1 ``` ### Logs & Screenshots ### Browser console logs The browser console repeatedly showed: ```text [tiptap warn]: Duplicate extension names found: ['codeBlock', 'bulletList', 'listItem', 'listKeymap', 'orderedList']. This can lead to issues. ```` Repeated rendering / performance warnings: ```text ResponseMessage.svelte:593 [Violation] Added non-passive event listener to a scroll-blocking 'wheel' event. Forced reflow while executing JavaScript took 50ms ``` ### API response check The chat endpoint returned HTTP 200: ```text Request URL: https://url/api/v1/chats/c42c4393-0cec-46cc-8053-c06b21a53789 Request Method: GET Status Code: 200 OK ``` But the frontend still showed infinite Loading. ### Active task check I also tried: ```js await fetch('/api/v1/tasks/active/chats', { credentials: 'include', headers: { Accept: 'application/json' } }).then(r => r.json()) ``` In my environment this returned HTML instead of JSON: ```text Unexpected token '<', "<!doctype "... is not valid JSON ``` Further inspection showed: ```text status: 200 content-type: text/html; charset=utf-8 <!doctype html> <html lang="en"> ... ``` So this endpoint was not useful in my current version/setup. ### Unfinished message check I checked whether any messages had `done: false` or pending status: ```js Object.entries(messages) .filter(([id, m]) => m.done === false || m.error || m.status === 'pending') ``` The result was: ```text unfinished: [] ``` So this was not a normal unfinished-generation state. ### Malformed node details The problematic node was: ```text ecb2c670-f1b7-46e0-a1ab-ee675dfe739a ``` Its keys were: ```text done content output usage statusHistory ``` It did not contain: ```text role parentId childrenIds timestamp ``` The content included: ```text The request was rejected because it was considered high risk ``` ### Docker logs Relevant container logs around restart showed normal startup messages such as: ```text Loading WEBUI_SECRET_KEY from file, not provided as an environment variable. Loading WEBUI_SECRET_KEY from .webui_secret_key INFO [alembic.runtime.migration] Context impl SQLiteImpl. INFO [alembic.runtime.migration] Will assume non-transactional DDL. WARNING: CORS_ALLOW_ORIGIN IS SET TO '*' - NOT RECOMMENDED FOR PRODUCTION DEPLOYMENTS. ``` No clear backend exception was visible in the short log excerpt I checked. ### Manual database repair output I manually repaired the SQLite database by deleting the malformed orphan node and setting `history.currentId` to the last valid leaf message. Repair output: ```text before currentId: ecb2c670-f1b7-46e0-a1ab-ee675dfe739a before message count: 65 deleted bad node: ecb2c670-f1b7-46e0-a1ab-ee675dfe739a after currentId: 35bfac66-bdbf-4147-ab58-04c4064daeef after message count: 64 repair done ``` ### Additional Information ## Root cause hypothesis The immediate cause appears to be: ```text chat.history.currentId points to a malformed object that is not a valid OpenWebUI message. ```` The trigger was an upstream provider-side safety rejection: ```text The request was rejected because it was considered high risk ``` However, the safety rejection itself should not permanently break a chat. The more important issue is that the rejected provider response appears to have been saved into `chat.history.messages` without being normalized into OpenWebUI's expected message schema. The malformed object looked more like a raw provider response or Responses-API-style object: ```json { "done": true, "content": "...", "output": [...], "usage": {...}, "statusHistory": [...] } ``` instead of a valid chat message object: ```json { "id": "...", "role": "assistant", "content": "...", "parentId": "...", "childrenIds": [], "timestamp": 1234567890 } ``` ## Why this matters This issue significantly increases troubleshooting cost: * The backend API returns HTTP 200. * The UI only shows infinite Loading. * Browser console warnings point to Tiptap and scroll listeners, which are misleading. * The user has to inspect raw chat JSON. * Recovery requires manual SQLite database editing. * A single malformed provider response can make an entire chat unusable. * Non-technical users may have no practical recovery path. ## Suggested frontend safeguard Before rendering the current message, OpenWebUI could validate the node: ```ts const currentMessage = messages[currentId]; if ( !currentMessage || !currentMessage.role || !Array.isArray(currentMessage.childrenIds) ) { // Show a recoverable error instead of infinite Loading. // Optionally fall back to the last valid leaf message. } ``` The UI could show a message such as: ```text This chat contains an invalid message node and cannot render the selected branch. You can switch to the last valid message or attempt automatic repair. ``` ## Suggested backend safeguard Before saving a provider response into chat history, OpenWebUI could enforce a minimal message schema: ```ts { id: string; role: "user" | "assistant" | "system"; content: string; parentId: string | null; childrenIds: string[]; timestamp?: number; } ``` If an upstream response contains fields like: ```text done output usage statusHistory ``` but does not contain `role` or `childrenIds`, it should not be inserted directly into `history.messages`. ## Suggested repair behavior OpenWebUI could provide an automatic safe repair mechanism: 1. Detect whether `history.currentId` exists. 2. Check whether `history.messages[history.currentId]` is a valid message object. 3. If invalid, search for the last valid leaf message. 4. Set `history.currentId` to that valid leaf message. 5. Preserve the malformed object for diagnostics if needed. 6. Surface a warning to the user or admin. ## Related upstream provider behavior The upstream provider in this case was Xiaomi MiMo API through an OpenAI-compatible endpoint. I understand that the upstream provider should also return a valid OpenAI-compatible response for rejected requests. However, OpenWebUI can still protect users by validating message objects before saving them and by handling invalid `currentId` targets gracefully during rendering. This would make OpenWebUI more robust when dealing with third-party OpenAI-compatible providers, gateways, proxies, and safety-filter rejection responses. ## AI assistance disclosure This issue was drafted with AI assistance based on a real debugging session, browser console output, OpenWebUI chat JSON inspection, and a manual SQLite repair process provided by the user. AI assistance details: ```text AI provider: OpenAI AI product: ChatGPT Model: GPT-5.5 Thinking Model type: reasoning-oriented large language model Primary capabilities used: technical debugging, log analysis, JSON structure analysis, root-cause summarization, issue drafting Knowledge cutoff: 2025-08 Generation date: 2026-04-26 Output language: English User-provided evidence used: OpenWebUI console logs, malformed message object fields, currentId value, validation output, repair script output Direct access to user's server: No Direct modification of user's environment: No Official statement from OpenWebUI: No Official statement from Xiaomi MiMo: No ``` Model parameter and performance disclosure: ```text Exact inference parameters: Not exposed to the end user. Values such as temperature, top_p, frequency_penalty, presence_penalty, seed, and internal routing parameters are not available. Context capability: The model supports long-context technical reasoning and multi-turn debugging, but an exact publicly disclosed context window value was not available in this session. Performance profile: Optimized for multi-step reasoning, technical analysis, code and log interpretation, structured writing, and root-cause explanation. Limitations: The issue text is based on user-provided evidence and observable behavior. It should not be treated as an official RCA from OpenWebUI or Xiaomi MiMo. The exact upstream API behavior should still be verified by maintainers using server-side logs and reproducible test cases. ```

GiteaMirror added the bug label 2026-05-06 00:19:52 -05:00

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

dev

v0.10.2

v0.10.1

v0.10.0

v0.9.6

v0.9.5

v0.9.4

v0.9.3

v0.9.2

v0.9.1

v0.9.0

v0.8.12

v0.8.11

v0.8.10

v0.8.9

v0.8.8

v0.8.7

v0.8.6

v0.8.5

v0.8.4

v0.8.3

v0.8.2

v0.8.1

v0.8.0

v0.7.2

v0.7.1

v0.7.0

v0.6.43

v0.6.42

v0.6.41

v0.6.40

v0.6.39

v0.6.38

v0.6.37

v0.6.36

v0.6.35

v0.6.34

v0.6.33

v0.6.32

v0.6.31

v0.6.30

v0.6.29

v0.6.28

v0.6.27

v0.6.26

v0.6.25

v0.6.24

v0.6.23

v0.6.22

v0.6.21

v0.6.20

v0.6.19

v0.6.18

v0.6.17

v0.6.16

v0.6.15

v0.6.14

v0.6.13

v0.6.12

v0.6.11

v0.6.10

v0.6.9

v0.6.8

v0.6.7

v0.6.6

v0.6.5

v0.6.4

v0.6.3

v0.6.2

v0.6.1

v0.6.0

v0.5.20

v0.5.19

v0.5.18

v0.5.17

v0.5.16

v0.5.15

v0.5.14

v0.5.13

v0.5.12

v0.5.11

v0.5.10

v0.5.9

v0.5.8

v0.5.7

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.8

v0.4.7

v0.4.6

v0.4.5

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.35

v0.3.34

v0.3.33

v0.3.32

v0.3.31

v0.3.30

v0.3.29

v0.3.28

v0.3.27

v0.3.26

v0.3.25

v0.3.24

v0.3.23

v0.3.22

v0.3.21

v0.3.20

v0.3.19

v0.3.18

v0.3.17

v0.3.16

v0.3.15

v0.3.14

v0.3.13

v0.3.12

v0.3.11

v0.3.10

v0.3.9

v0.3.8

v0.3.7

v0.3.6

v0.3.5

v0.3.4

v0.3.3

v0.3.2

v0.3.1

v0.3.0

v0.2.5

v0.2.4

v0.2.3

v0.2.2

v0.2.1

v0.2.0

v0.1.125

v0.1.124

v0.1.123

v0.1.122

v0.1.121

v0.1.120

v0.1.119

v0.1.118

v0.1.117

v0.1.116

v0.1.115

v0.1.114

v0.1.113

v0.1.112

v0.1.111

v0.1.110

v0.1.109

v0.1.108

v0.1.107

v0.1.106

v0.1.105

v0.1.104

v0.1.103

v0.1.102

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

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#58880