[GH-ISSUE #14806] issue: UI gets stuck in loading state when switching back to conversation with revoked model permissions #17368

New Issue

GiteaMirror · 2026-04-19T23:06:00-05:00

GiteaMirror commented

2026-04-19 23:06:00 -05:00

Originally created by @ShirasawaSama on GitHub (Jun 9, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/14806

Check Existing Issues

I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.

Installation Method

Git Clone

Open WebUI Version

v0.6.14 (dev)

Ollama Version (if applicable)

No response

Operating System

MacOS 15.5

Browser (if applicable)

Edge Latest

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

After permissions are restored, the conversation should load normally when switching back.

There should be other more humane display information presented to users.

To be precise, I am not sure what should ultimately be presented to users, so I am currently unable to submit a PR.

Actual Behavior

During permission issues: Correctly shows "Model not found" for new messages
After switching conversations and returning: Gets stuck in loading state indefinitely in both scenarios

Steps to Reproduce

Grant a user access to an AI model
User starts a conversation and sends messages using that model
Admin revokes the user's permission for that model while the conversation is active
User continues to ask questions in the same conversation
- ✅ Expected: UI correctly displays "Model not found" error
Admin restores the user's permission for that model
- or User sends multiple additional messages in the same conversation without permission for that model
User switches to a different conversation, then switches back to the previous conversation
- ❌ Bug: UI gets stuck in a loading state instead of displaying the conversation normally

Logs & Screenshots

After admin restores the user's permission for that model:

Additional Information

This creates a confusing user experience where conversations become inaccessible after any permission-related issues occur, even when permissions are restored or when the conversation should simply display previous error messages.

Originally created by @ShirasawaSama on GitHub (Jun 9, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/14806 ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Git Clone ### Open WebUI Version v0.6.14 (dev) ### Ollama Version (if applicable) _No response_ ### Operating System MacOS 15.5 ### Browser (if applicable) Edge Latest ### 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 After permissions are restored, the conversation should load normally when switching back. There should be other more humane display information presented to users. _To be precise, I am not sure what should ultimately be presented to users, so I am currently unable to submit a PR._ ### Actual Behavior - During permission issues: Correctly shows "Model not found" for new messages - After switching conversations and returning: Gets stuck in loading state indefinitely in both scenarios ### Steps to Reproduce 1. Grant a user access to an AI model 2. User starts a conversation and sends messages using that model 3. Admin revokes the user's permission for that model while the conversation is active 4. User continues to ask questions in the same conversation - ✅ Expected: UI correctly displays "Model not found" error 5. Admin restores the user's permission for that model - or User sends multiple additional messages in the same conversation without permission for that model 6. User switches to a different conversation, then switches back to the previous conversation - ❌ Bug: UI gets stuck in a loading state instead of displaying the conversation normally ### Logs & Screenshots ![Image](https://github.com/user-attachments/assets/69da6c46-ccfb-45ce-8fb8-557c32cd579d) After admin restores the user's permission for that model: ![Image](https://github.com/user-attachments/assets/e73f6bf1-38de-4542-a6bb-41f582ee6142) ### Additional Information This creates a confusing user experience where conversations become inaccessible after any permission-related issues occur, even when permissions are restored or when the conversation should simply display previous error messages.

GiteaMirror added the confirmed issue bug labels 2026-04-19 23:06:00 -05:00

GiteaMirror commented

2026-04-19 23:06:02 -05:00

@silentoplayz commented on GitHub (Oct 24, 2025):

I believe this issue is reproducible with the provided reproduction steps. The previous Model Not Found banner-like error is replaced with the thinking/loading indicator dot when I click away from and go back to the chat I tested with.

@silentoplayz commented on GitHub (Oct 24, 2025): I believe this issue is reproducible with the provided reproduction steps. The previous `Model Not Found` banner-like error is replaced with the thinking/loading indicator dot when I click away from and go back to the chat I tested with. <img width="2299" height="938" alt="Image" src="https://github.com/user-attachments/assets/2a9bb245-f22a-4bab-a443-3fc77af9befa" />

GiteaMirror commented

2026-04-19 23:06:02 -05:00

@silentoplayz commented on GitHub (Dec 15, 2025):

This is still reproducible on the latest dev commit, but is it actually a bug? What do you expect to see other than the loading indicator dot when it comes to your reproduction steps? Once you restore the user's permission to the model, the user wouldn't expect to see the "Model not found" error in their chat upon returning back to it, because it simply wouldn't be true anymore.

❌ Bug: UI gets stuck in a loading state instead of displaying the conversation normally

I just don't see this being a bug, as the model never provided a response initially due to the user not having permission. Before, you would've saw the Model not found error.

@silentoplayz commented on GitHub (Dec 15, 2025): This is still reproducible on the latest `dev` commit, but is it actually a bug? What do you expect to see other than the loading indicator dot when it comes to your reproduction steps? Once you restore the user's permission to the model, the user wouldn't expect to see the "Model not found" error in their chat upon returning back to it, because it simply wouldn't be true anymore. > ❌ Bug: UI gets stuck in a loading state instead of displaying the conversation normally I just don't see this being a bug, as the model never provided a response initially due to the user not having permission. Before, you would've saw the `Model not found` error.

GiteaMirror commented

2026-04-19 23:06:03 -05:00

@ShirasawaSama commented on GitHub (Dec 16, 2025):

@silentoplayz I believe the best approach is to prevent users from sending messages. Common solutions include displaying a toast notification or showing an error directly in the model's response after the attempt. The current persistent “loading” status is highly unusual and will lead users to assume it's a bug.

@ShirasawaSama commented on GitHub (Dec 16, 2025): @silentoplayz I believe the best approach is to prevent users from sending messages. Common solutions include displaying a toast notification or showing an error directly in the model's response after the attempt. The current persistent “loading” status is highly unusual and will lead users to assume it's a bug.

GiteaMirror commented

2026-04-19 23:06:04 -05:00

@silentoplayz commented on GitHub (Dec 16, 2025):

Common solutions include displaying a toast notification or showing an error directly in the model's response after the attempt.

But displaying an error directly in place of the model's response is what triggers this issue. I agree with preventing a message from being sent to a model that the user no longer has access to. Displaying a toast notification to the user about the model not being found may be more ideal here, as it would prevent a message being sent to a model that isn't found in the first place.

@silentoplayz commented on GitHub (Dec 16, 2025): > Common solutions include displaying a toast notification or showing an error directly in the model's response after the attempt. But displaying an error directly **in place** of the model's response is what triggers this issue. I agree with preventing a message from being sent to a model that the user no longer has access to. Displaying a toast notification to the user about the model not being found may be more ideal here, as it would prevent a message being sent to a model that isn't found in the first place.

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#17368