mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 19:08:59 -05:00
[GH-ISSUE #22525] issue: Active chat task stuck in loading state after server restart — stale task data in Redis cannot be cleared #35263
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#35263
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 (Mar 10, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/22525
Check Existing Issues
Installation Method
Git Clone
Open WebUI Version
v0.8.10
Ollama Version (if applicable)
No response
Operating System
MacOS 26
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
When a chat's streaming/generation task has fully completed (all messages have
"done": true), the chat should not appear in the active tasks list. The sidebar should show no loading indicator, and the message input area should display the normal send button. If a stale task somehow persists, clicking the "Stop" button should successfully clear the task from Redis and remove the chat from the/api/v1/tasks/active/chatsresponse, restoring the UI to its normal state.Actual Behavior
After a server restart, there is a small probability that a completed chat's task ID remains orphaned in Redis. This causes the following cascade of issues:
"done": true./api/v1/tasks/active/chatscontinues to return the stale chat ID (e.g.,{"active_chat_ids": ["..."]}).Steps to Reproduce
docker restart, process restart, or deployment rollout) while the task is in progress or has just completed.GET /api/v1/tasks/active/chatsreturns the stale chat ID inactive_chat_ids./api/v1/tasks/active/chatsstill returns the same stale chat ID — the Redis entry was not cleared.Logs & Screenshots
Data from the
/api/v1/tasks/active/chatsAPI after multiple server restarts and clicking the stop chat button:/api/tasks/chat/{chatId}:After called
/api/tasks/stop/61b0b8a1-c9c1-4c65-{....}:However, after refreshing the page, the task is still there.
Additional Information
No response
@snesan821 commented on GitHub (Mar 25, 2026):
I'm spinning up a local environment to tackle this.
Tracing the logs, this looks like a classic orphaned lock issue: the background worker is killed during the server restart and never gets the chance to clean up its own task_id from the cache. When the /stop endpoint is called later, it just broadcasts to a dead worker.
I'm putting together a PR to do two things:
Update the /api/v1/tasks/stop logic to explicitly delete the task and chat IDs from the cache/Redis instead of just sending an abort signal.
Add a cleanup routine to the FastAPI lifespan/startup event to flush the active tasks registry on boot, ensuring a clean slate after any hard restart.
Will link the PR shortly!