mirror of
https://github.com/open-webui/open-webui.git
synced 2026-07-16 14:39:31 -05:00
[GH-ISSUE #19225] issue: Chat history cannot be displayed and remains loading indefinitely #122122
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#122122
Reference in New Issue
Block a user
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?
Originally created by @ShirasawaSama on GitHub (Nov 17, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/19225
Check Existing Issues
Installation Method
Git Clone
Open WebUI Version
v0.6.36
Ollama Version (if applicable)
No response
Operating System
MacOS 26
Browser (if applicable)
Edge 141
Confirmation
README.md.Expected Behavior
Chat history can be displayed
Actual Behavior
Chat history cannot be displayed and remains loading indefinitely
Steps to Reproduce
It is unclear what caused this data; further investigation may be required.
Logs & Screenshots
Additional Information
We can see that the data returned by the
/api/v1/chats/endpoint includes the complete chat history:However, we can see that the chat message corresponding to currentId lacks parentId and other fields, causing it to keep loading.
I'm not sure what caused this data issue.
@rgaricano commented on GitHub (Nov 17, 2025):
you can try a chat check tool for check &| fix it: https://github.com/open-webui/open-webui/issues/15189#issuecomment-3333298297 (https://discord.com/channels/1170866489302188073/1210732510250541067/1420781986041167932 )
@ShirasawaSama commented on GitHub (Nov 17, 2025):
Thanks, but I tried importing this function, but it shows this. Is my import location incorrect?
@Algorithm5838 commented on GitHub (Nov 17, 2025):
A workaround for me is to click the three dots, select Overview, and then choose a chat branch.
@ShirasawaSama commented on GitHub (Nov 17, 2025):
Since more than one person has encountered this issue, it clearly indicates that this is a reproducible bug. I believe we need to figure out how to consistently reproduce the bug.
@rgaricano commented on GitHub (Nov 17, 2025):
Use the tool (first I did the function but finally I worked & improved the tool)
@tjbck commented on GitHub (Nov 17, 2025):
@ShirasawaSama indeed, no one has came up with a way to reliably reproduce this issue which makes it extremely challenging to address.
@DominikStarke commented on GitHub (Nov 23, 2025):
I found that if a mcp server is unavailable chats don't load until connection to the offending server times out.
@ShirasawaSama commented on GitHub (Nov 24, 2025):
@rgaricano This doesn't seem to be working.
@i-iooi-i commented on GitHub (Nov 25, 2025):
I've previously experienced a problem where, if the large language model hasn't responded in a chat—presumably due to network issues—and I navigate away from and then back to the current chat page, the page content fails to load, regardless of how long I wait.
A similar scenario arises in extended conversations, particularly those incorporating images, where the page becomes significantly sluggish. Should the LLM still be pending a response due to network problems, and I delete my last sent message before exiting and re-entering the page, it remains in a perpetual loading state, unable to render content no matter the waiting period.
While I suspect network connectivity is the underlying cause, I cannot confirm it definitively. This issue is notably more common when using mobile devices. Although it manifested in several earlier versions, it seems to have been resolved in the two most recent updates.
There is indeed a discussion about this in some communities: https://linux.do/t/topic/451908
@ShirasawaSama commented on GitHub (Nov 25, 2025):
@i-iooi-i For images in base64 format within chats, you can attempt to mitigate this by setting the environment variable
REPLACE_IMAGE_URLS_IN_CHAT_RESPONSE=truein the latest v0.6.38 version.@i-iooi-i commented on GitHub (Nov 25, 2025):
@ShirasawaSama Okay, thank you very much, I just added the environment variable. 🌹
@rgaricano commented on GitHub (Nov 25, 2025):
DryRun valve have to be manually disabled, model can't enable or disable it (the model's question to fix it directly it's a "hallucination")
@tjbck commented on GitHub (Nov 27, 2025):
ff4b1b9824might prevent this issue from occurring, more testing in general is needed here.@y525455383 commented on GitHub (Dec 4, 2025):
经常出现这个bug，真的很烦人，不知道是否能修复解决
@Sorkai commented on GitHub (Dec 8, 2025):
I have also encountered a similar issue where some specific conversations will cause the CPU utilization to spike to 100% and persist for over a minute when being loaded. This situation does not occur when the browser cache is disabled. I tried to analyze the page using a performance analysis tool, but the performance analysis tool clears the cache by default before loading. I am not very familiar with browser debugging tools and don't know how to inspect this type of problem.
However, I did notice that when this issue occurs, the request for loading this conversation returns an empty {"task_ids": []} (as shown in the image), and it is followed by a pending WebSocket request. The interval in the middle of this WebSocket (in the yellow box) is exactly the time period when the conversation loading was stuck. I don't know what the connection between them is. I checked the server logs but did not find any abnormalities.
Perhaps I need some special tools to inspect this problem.
Or maybe this is a new problem? Should I open a new issue?
@ShirasawaSama commented on GitHub (Dec 8, 2025):
@Sorkai Personally, I'm inclined to think it's a new issue. I suggest you export the chat data as JSON and send it out for debugging.
@aristosv commented on GitHub (Dec 11, 2025):
same issue here. this is the error in the browser
/api/v1/channels/:1 Failed to load resource: the server responded with a status of 401 (Unauthorized)
@Classic298 commented on GitHub (Dec 11, 2025):
@aristosv this is fixed in dev
@ShirasawaSama commented on GitHub (Jan 5, 2026):
@Classic298 4b356a3 This commit doesn't appear to have been merged into the dev branch. I tested it, and the currently corrupted chat history still remains in a continuous loading state.
@ShirasawaSama commented on GitHub (Mar 9, 2026):
@Classic298
I am still encountering this issue and it doesn't seem to have been fixed in 0.8.10 (Including newly generated data). There may be the following situations:
So I added this code at the end of the getChatById function to fix it:
@ShirasawaSama commented on GitHub (Mar 29, 2026):
#23179
@Classic298 commented on GitHub (Mar 29, 2026):
we now know what causes this and how to reproduce it thanks t @ShirasawaSama cc @tjbck
@ShirasawaSama commented on GitHub (Mar 29, 2026):
In fact, this is caused by an asynchronous race condition between the three endpoints—/chats/new, post /chats/:id, and /completions—due to improper locking.
@silenceroom commented on GitHub (May 5, 2026):
experience the same problem on our instance too. some users have long chat session and the loading now goes to infinite spin when try to retrieve the chat session. Have to create a new one and get rid of the broken chat.
@JeslynMcKenzie commented on GitHub (May 11, 2026):
Has this been fixed in any published versions or at least has a workaround to fix broken chats?
@Classic298 commented on GitHub (May 11, 2026):
Yeah this should've been long fixed now in latest versions