[GH-ISSUE #22525] issue: Active chat task stuck in loading state after server restart — stale task data in Redis cannot be cleared #58400

New Issue

GiteaMirror · 2026-05-05T23:05:54-05:00

GiteaMirror commented

2026-05-05 23:05:54 -05:00

Originally created by @ShirasawaSama on GitHub (Mar 10, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/22525

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

Git Clone

Open WebUI Version

v0.8.10

Ollama Version (if applicable)

No response

Operating System

MacOS 26

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

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/chats response, 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:

Sidebar: The affected chat permanently displays a loading/spinning indicator.
Chat view: When opening the conversation, the input area shows a "Stop generation" button instead of the normal send button, even though all messages in the conversation already have "done": true.
Stop button ineffective: Clicking the stop button returns a successful API response, but the stale task entry in Redis is not actually removed.
Persists across page reloads: Refreshing the page brings back the exact same broken state — the loading indicator reappears in the sidebar, the stop button returns in the chat view, and /api/v1/tasks/active/chats continues to return the stale chat ID (e.g., {"active_chat_ids": ["..."]}).
The only way to resolve this currently would be to manually delete the key from Redis, which is not accessible to end users.

Steps to Reproduce

Note

: This is not 100% reproducible — it occurs with low probability and appears to be a race condition during server restart.

Have an active chat with an ongoing streaming/generation task in Redis.
Restart the Open WebUI server (e.g., docker restart, process restart, or deployment rollout) while the task is in progress or has just completed.
After the server comes back up, open the Web UI.
Observe (if the race condition is triggered):
- The sidebar shows a loading spinner on the affected chat.
- Opening the chat shows the "Stop" button instead of the "Send" button.
- Calling GET /api/v1/tasks/active/chats returns the stale chat ID in active_chat_ids.
Click the "Stop" button in the chat view.
Observe: The API responds with success, but:
- The sidebar still shows the loading indicator.
- Refreshing the page restores the broken state.
- /api/v1/tasks/active/chats still returns the same stale chat ID — the Redis entry was not cleared.

Logs & Screenshots

Data from the /api/v1/tasks/active/chats API 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

Originally created by @ShirasawaSama on GitHub (Mar 10, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/22525 ### 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 Git Clone ### Open WebUI Version v0.8.10 ### Ollama Version (if applicable) _No response_ ### Operating System MacOS 26 ### 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 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/chats` response, 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: 1. **Sidebar**: The affected chat permanently displays a loading/spinning indicator. 2. **Chat view**: When opening the conversation, the input area shows a "Stop generation" button instead of the normal send button, even though all messages in the conversation already have `"done": true`. 3. **Stop button ineffective**: Clicking the stop button returns a successful API response, but the stale task entry in Redis is **not** actually removed. 4. **Persists across page reloads**: Refreshing the page brings back the exact same broken state — the loading indicator reappears in the sidebar, the stop button returns in the chat view, and `/api/v1/tasks/active/chats` continues to return the stale chat ID (e.g., `{"active_chat_ids": ["..."]}`). 5. The only way to resolve this currently would be to manually delete the key from Redis, which is not accessible to end users. ### Steps to Reproduce > **Note**: This is **not** 100% reproducible — it occurs with low probability and appears to be a race condition during server restart. 1. Have an active chat with an ongoing streaming/generation task in Redis. 2. Restart the Open WebUI server (e.g., `docker restart`, process restart, or deployment rollout) while the task is in progress or has just completed. 3. After the server comes back up, open the Web UI. 4. **Observe** (if the race condition is triggered): - The sidebar shows a loading spinner on the affected chat. - Opening the chat shows the "Stop" button instead of the "Send" button. - Calling `GET /api/v1/tasks/active/chats` returns the stale chat ID in `active_chat_ids`. 5. Click the "Stop" button in the chat view. 6. **Observe**: The API responds with success, but: - The sidebar still shows the loading indicator. - Refreshing the page restores the broken state. - `/api/v1/tasks/active/chats` still returns the same stale chat ID — the Redis entry was not cleared. ### Logs & Screenshots <img width="538" height="72" alt="Image" src="https://github.com/user-attachments/assets/e795079b-02bf-4a7f-9803-fc827ab8d556" /> <img width="404" height="258" alt="Image" src="https://github.com/user-attachments/assets/05134ff6-8f58-48ab-ac60-44efcf4d14ed" /> Data from the `/api/v1/tasks/active/chats` API after multiple server restarts and clicking the stop chat button: <img width="1060" height="178" alt="Image" src="https://github.com/user-attachments/assets/3e25441a-082d-4b0f-937e-7ddd6d7b3939" /> `/api/tasks/chat/{chatId}`: <img width="1052" height="240" alt="Image" src="https://github.com/user-attachments/assets/efb25a7e-c1c9-4b01-b3f8-7e54852c28f1" /> After called `/api/tasks/stop/61b0b8a1-c9c1-4c65-{....}`: <img width="1278" height="142" alt="Image" src="https://github.com/user-attachments/assets/54e2bfdc-c751-4d14-a015-b9b0a8cdca74" /> However, after refreshing the page, the task is still there. ### Additional Information _No response_

GiteaMirror added the bug label 2026-05-05 23:05:54 -05:00

GiteaMirror commented

2026-05-05 23:05:55 -05:00

@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!

@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!

GiteaMirror commented

2026-05-05 23:05:56 -05:00

@ahmedtawfik3k commented on GitHub (May 5, 2026):

To add to this, it happens not only with restarts, but after the conversation ends, it keeps rotating like this for a long time

sometimes even if you close the tab and open again.

@ahmedtawfik3k commented on GitHub (May 5, 2026): To add to this, it happens not only with restarts, but after the conversation ends, it keeps rotating like this for a long time <img width="256" height="35" alt="Image" src="https://github.com/user-attachments/assets/5981405c-5553-4329-b5f6-7cfe6db9f97e" /> sometimes even if you close the tab and open again.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#58400