mirror of
https://github.com/open-webui/open-webui.git
synced 2026-03-11 08:15:00 -05:00
Unresponsive conversation after auto-continue action #1839
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 @rndmcnlly on GitHub (Aug 21, 2024).
Bug Report
Installation Method
Docker
Environment
Open WebUI Version: v0.3.13
Ollama (if applicable): n/a
Operating System: Ubuntu 24.04 LTS
Browser (if applicable): Crome, Version 127.0.6533.120 (Official Build) (arm64)
Confirmation:
Expected Behavior:
When I dispatch the event
{"type": "action", "data": {"action": "continue"}}in a filter outlet, I want it to have the same effect as if the user had pressed the Continue Response button in the UI.Actual Behavior:
See screenshot below. The continued result does not display in the UI, and the buttons below the rely disappear. Further, the UI does not respond to additional user messages. The continuation seems to happen on the backend, but the page does not update. Refreshing the page makes the conversation responsive again, but the continued text is still not visible in the conversation history.
Description
Bug Summary:
Dispatching a continue action from a filter outlet leads to an unresponsive UI state.
Reproduction Details
Steps to Reproduce:
Install this filter, enabled globally:
Then, start a new conversation with a message like:
Say just "MEOW" on a line by itself. Later, when the conversation continues, comment on the history of the conversation so far (i.e. whether you were able to follow instructions correctly).When the filter is enabled, the conversation becomes unresponsive.
When the filter is disabled, the conversation remains responsive, and the result of manually pressing Continue Response looks like
MEOWI've followed your instructions correctly by responding with "MEOW" as requested. How can I assist you further?as expected.Logs and Screenshots
Browser Console Logs:
No relevant differences appear between the enabled and disabled scenarios in the browser console. In particular, I see a similar sequence of "chat.completion.chunk" message scroll by showing that the continuation is indeed streaming back form the backend in both scenarios.
Docker Container Logs:
With filter ENABLED
Note that the second
outletstrangely message does not show any new data (despite the fact that I saw the new text scroll by in chunks in the browser log).With filter DISABLED (and manually pressing Continue Response)
The logs show mostly the same sequence of
INFOlines above. Of course, there are noAUTO_CONTINUElines because the filter was disabled.With filter EDITED (and manually pressing Continue Response)
If I edit the code of the filter to comment out the
ifblock ofoutlet, I can now see that the outlet does get to see the expected completion. This makes me thing the root cause of the problem is in the front end rather than back end.Screenshots/Screen Recordings (if applicable):
Additional Information
It might seem silly to auto-continue if the assistant says "MEOW", but this is just an attempt to simplify a buggy scenario that resulted from a much larger and more interesting application.
I suspect the issue has to do with the order in which various UI components update because things look okay on the back end. The fix might be as simple as wrapping the existing
continueButton.click();(inChat.svelte) to use userequestIdleCallbackor something.@tjbck commented on GitHub (Aug 23, 2024):
Taking a look. However, bug aside, you probably shouldn't use the action event to continue the response and stream the response using
__event_emitter__with message event from the outlet hook function instead.@tjbck commented on GitHub (Aug 23, 2024):
Seems to have been a filter issue, if you're editing a content you shouldn't return the body content which will override the messages.