[GH-ISSUE #21564] issue: "Edit" and "Continue Response" don't work properly #122829

New Issue

GiteaMirror · 2026-05-21T01:51:52-05:00

GiteaMirror commented

2026-05-21 01:51:52 -05:00

Originally created by @TheObserver-000 on GitHub (Feb 18, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/21564

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

Docker

Open WebUI Version

0.8.3

Ollama Version (if applicable)

0.16.1

Operating System

Windows 11

Browser (if applicable)

Chrome 145

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

"Continue Response" must complete the "Paris is the capital of" with "France." and further attempts with "Continue Response" should not generate anything else because the response is finished, as the prompt says.

Actual Behavior

"Edit" Doesn't actually edit the message, and "Continue Response" generates an additional response instead of continuing the current one.

Steps to Reproduce

See the attached video.

Logs & Screenshots

https://github.com/user-attachments/assets/8a16b5ee-3956-40e7-b108-f171a379211f

Additional Information

No response

Originally created by @TheObserver-000 on GitHub (Feb 18, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/21564 ### 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 Docker ### Open WebUI Version 0.8.3 ### Ollama Version (if applicable) 0.16.1 ### Operating System Windows 11 ### Browser (if applicable) Chrome 145 ### 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 "Continue Response" must complete the "Paris is the capital of" with "France." and further attempts with "Continue Response" should not generate anything else because the response is finished, as the prompt says. ### Actual Behavior "Edit" Doesn't actually edit the message, and "Continue Response" generates an additional response instead of continuing the current one. ### Steps to Reproduce See the attached video. ### Logs & Screenshots https://github.com/user-attachments/assets/8a16b5ee-3956-40e7-b108-f171a379211f ### Additional Information _No response_

GiteaMirror added the bug label 2026-05-21 01:51:52 -05:00

GiteaMirror closed this issue

2026-05-21 01:51:53 -05:00

GiteaMirror commented

2026-05-21 01:51:56 -05:00

@Ghosthree3 commented on GitHub (Feb 18, 2026):

It has broken in two stages since 0.8.0.

In 0.8.0 responses that had been completed when edited would begin to write output from the end of where you edited the message, but appended to the original completed message. So in your video example, if you deleted 'France.' and hit continue it would output, "Paris is the capital of France.France.". If you stopped the output before it managed to complete then the continue output would function as intended after editing the response.

Then in 0.8.2 it broke further, now edits are ignored entirely and pressing continue gives an appended output similar to if you had pressed regenerate, appended to whatever the previous final output was (as shown in your video).

I've pinned to 0.8.1 for the time being as while it is annoying to lose the continue functionality if the output does complete, if I continuously catch and stop it before it does then it functions as it used to prior to 0.8.0 (and if it does complete I hit regenerate and quickly stop and paste in my edited output before continuing).

@Ghosthree3 commented on GitHub (Feb 18, 2026): It has broken in two stages since 0.8.0. In 0.8.0 responses that had been _completed_ when edited would begin to write output from the end of where you edited the message, but appended to the original completed message. So in your video example, if you deleted 'France.' and hit continue it would output, "Paris is the capital of France.France.". If you stopped the output before it managed to complete then the continue output would function as intended after editing the response. Then in 0.8.2 it broke further, now edits are ignored entirely and pressing continue gives an appended output similar to if you had pressed regenerate, appended to whatever the previous final output was (as shown in your video). I've pinned to 0.8.1 for the time being as while it is annoying to lose the continue functionality if the output does complete, if I continuously catch and stop it before it does then it functions as it used to prior to 0.8.0 (and if it does complete I hit regenerate and quickly stop and paste in my edited output before continuing).

GiteaMirror commented

2026-05-21 01:51:58 -05:00

@MrOutsider commented on GitHub (Feb 20, 2026):

Same issue to the T.
My Ollama version is 0.16.2

@MrOutsider commented on GitHub (Feb 20, 2026): Same issue to the T. My Ollama version is 0.16.2

GiteaMirror commented

2026-05-21 01:51:59 -05:00

@quark6789 commented on GitHub (Feb 21, 2026):

I have encountered the same thing.

Installation method: uv
Open WebUI version: 0.8.3
LM Studio version: 0.4.3
OS: macOS Tahoe 26.3 and iOS 26.2.1
Browser: Safari (on both macOS and iOS)

@quark6789 commented on GitHub (Feb 21, 2026): I have encountered the same thing. - Installation method: uv - Open WebUI version: 0.8.3 - LM Studio version: 0.4.3 - OS: macOS Tahoe 26.3 and iOS 26.2.1 - Browser: Safari (on both macOS and iOS)

GiteaMirror commented

2026-05-21 01:52:00 -05:00

@TheObserver-000 commented on GitHub (Feb 23, 2026):

As of v0.8.5, it's still not fixed

@TheObserver-000 commented on GitHub (Feb 23, 2026): As of v0.8.5, it's still not fixed

GiteaMirror commented

2026-05-21 01:52:01 -05:00

@andrewmm511 commented on GitHub (Feb 23, 2026):

Same. I use the continue functionality every day for pre-fill.

@andrewmm511 commented on GitHub (Feb 23, 2026): Same. I use the continue functionality every day for pre-fill.

GiteaMirror commented

2026-05-21 01:52:02 -05:00

@Varalan commented on GitHub (Feb 26, 2026):

I'm getting the same exact thing with 0.8.5/docker/LM Studio 0.4.4

@Varalan commented on GitHub (Feb 26, 2026): I'm getting the same exact thing with 0.8.5/docker/LM Studio 0.4.4

GiteaMirror commented

2026-05-21 01:52:03 -05:00

@BillyJin-NSRL-V-KVSHIN commented on GitHub (Mar 3, 2026):

0.8.8, still not fixed

@BillyJin-NSRL-V-KVSHIN commented on GitHub (Mar 3, 2026): 0.8.8, still not fixed

GiteaMirror commented

2026-05-21 01:52:03 -05:00

@MenceyBentayga commented on GitHub (Mar 8, 2026):

PR still hasn't gone through at 0.8.9, saying it's waiting for a maintainer.

Isn't it kind of a basic feature to wait two weeks on?

@MenceyBentayga commented on GitHub (Mar 8, 2026): PR still hasn't gone through at 0.8.9, saying it's waiting for a maintainer. Isn't it kind of a basic feature to wait two weeks on?

GiteaMirror commented

2026-05-21 01:52:05 -05:00

@frenzybiscuit commented on GitHub (Mar 8, 2026):

Same issue.

I will let the LLM respond. Then I will go back and edit the LLM message.

Then, I reply.

It will recall the deleted portion of the response.

@frenzybiscuit commented on GitHub (Mar 8, 2026): Same issue. I will let the LLM respond. Then I will go back and edit the LLM message. Then, I reply. It will recall the deleted portion of the response.

GiteaMirror commented

2026-05-21 01:52:05 -05:00

@MenceyBentayga commented on GitHub (Mar 9, 2026):

As of 0.8.10, the 20-line pull request is still waiting for a maintainer to see it since two weeks ago. Hopefully it is possible to merge the fix such an important user-facing feature soon.

@MenceyBentayga commented on GitHub (Mar 9, 2026): As of 0.8.10, the 20-line pull request is still waiting for a maintainer to see it since two weeks ago. Hopefully it is possible to merge the fix such an important user-facing feature soon.

GiteaMirror commented

2026-05-21 01:52:07 -05:00

@Iniquitatis commented on GitHub (Mar 9, 2026):

important user-facing feature

I'd argue a fundamental feature.

@Iniquitatis commented on GitHub (Mar 9, 2026): > important user-facing feature I'd argue a fundamental feature.

GiteaMirror commented

2026-05-21 01:52:08 -05:00

@Classic298 commented on GitHub (Mar 9, 2026):

has anyone tested the PR? I see zero comments under the PR of people testing it and confirming it also has no downstream effects or unintended side effects.

It would definitely be easier for Tim to merge it if anyone here would actually also test the PR and help get it merged.

@Classic298 commented on GitHub (Mar 9, 2026): has anyone tested the PR? I see zero comments under the PR of people testing it and confirming it also has no downstream effects or unintended side effects. It would definitely be easier for Tim to merge it if anyone here would actually also test the PR and help get it merged.

GiteaMirror commented

2026-05-21 01:52:08 -05:00

@MenceyBentayga commented on GitHub (Mar 9, 2026):

has anyone tested the PR? I see zero comments under the PR of people testing it and confirming it also has no downstream effects or unintended side effects.

It would definitely be easier for Tim to merge it if anyone here would actually also test the PR and help get it merged.

Will do at my earliest possible chance and report back. Is there anything in particular that should be tested other than the visible stuff the changed code could affect?

@MenceyBentayga commented on GitHub (Mar 9, 2026): > has anyone tested the PR? I see zero comments under the PR of people testing it and confirming it also has no downstream effects or unintended side effects. > > It would definitely be easier for Tim to merge it if anyone here would actually also test the PR and help get it merged. Will do at my earliest possible chance and report back. Is there anything in particular that should be tested other than the visible stuff the changed code could affect?

GiteaMirror commented

2026-05-21 01:52:08 -05:00

@Classic298 commented on GitHub (Mar 9, 2026):

Test for the obvious which is what this issue is about

Continue response
Edit message

But also check around message branching
Edit your own message to create message branches and check if the correct branch is sent with the correct edited assistant message or correct continued response. And same if you branch the assistant message by regenerating the assistant message.

So yeah everything around message branching here should also be tested if that still behaves the same way and the fix correctly works for these cases also.

And what happens if i edit or continue response for older messages in the history

That's what i can think of right now would be good to test.

@Classic298 commented on GitHub (Mar 9, 2026): Test for the obvious which is what this issue is about Continue response Edit message But also check around message branching Edit your own message to create message branches and check if the correct branch is sent with the correct edited assistant message or correct continued response. And same if you branch the assistant message by regenerating the assistant message. So yeah everything around message branching here should also be tested if that still behaves the same way and the fix correctly works for these cases also. And what happens if i edit or continue response for older messages in the history That's what i can think of right now would be good to test.

GiteaMirror commented

2026-05-21 01:52:09 -05:00

@sayan1999 commented on GitHub (Mar 11, 2026):

please fix this this is very very important feature

@sayan1999 commented on GitHub (Mar 11, 2026): please fix this this is very very important feature

GiteaMirror commented

2026-05-21 01:52:10 -05:00

@sayan1999 commented on GitHub (Mar 15, 2026):

Why is none looking into this fundamental bug? Can anyone test the fix, and add comments to the pr?

@sayan1999 commented on GitHub (Mar 15, 2026): Why is none looking into this fundamental bug? Can anyone test the fix, and add comments to the pr?

GiteaMirror commented

2026-05-21 01:52:11 -05:00

@Classic298 commented on GitHub (Mar 15, 2026):

Hey @sayan1999 — to answer your questions directly:

"Why is no one looking into this?" — people are. Two PRs have been opened, one was closed because it was slop. The other is still open but someone already reported that the second PR is also not working at all. The issue is tracked. "No one looking into it" and "not yet merged" are very different things. Fixing message branching edge cases isn't a one-liner; there are real downstream risks which I outlined above, and a rushed merge of a broken fix is worse than the current state.

"Can anyone test the fix?" — Yes - you can. That's exactly what I asked the community to do a week ago. The PR has been sitting there with zero community-verified testing. If this feature matters enough for you to comment TWICE asking why it's not fixed, then it should matter enough for you to spend 10 minutes pulling the branch and running through the test cases I listed. That feedback directly helps Tim make the merge decision - or closing the second PR as well if it also turns out to not work.

Open source moves faster when people contribute, not just when they ask.

@Classic298 commented on GitHub (Mar 15, 2026): Hey @sayan1999 — to answer your questions directly: "Why is no one looking into this?" — people are. Two PRs have been opened, one was closed because it was slop. The other is still open but someone already reported that the second PR is also not working at all. The issue is tracked. "No one looking into it" and "not yet merged" are very different things. Fixing message branching edge cases isn't a one-liner; there are real downstream risks which I outlined above, and a rushed merge of a broken fix is worse than the current state. "Can anyone test the fix?" — Yes - <ins>**you can**</ins>. That's exactly what I asked the community to do a week ago. The PR has been sitting there with zero community-verified testing. If this feature matters enough for you to comment **TWICE** asking why it's not fixed, then it should matter enough for you to spend 10 minutes pulling the branch and running through the test cases I listed. That feedback directly helps Tim make the merge decision - or closing the second PR as well if it also turns out to not work. Open source moves faster when people contribute, not just when they ask.

GiteaMirror commented

2026-05-21 01:52:12 -05:00

@Classic298 commented on GitHub (Mar 15, 2026):

@MenceyBentayga any chance you got around to testing yet?

@Classic298 commented on GitHub (Mar 15, 2026): @MenceyBentayga any chance you got around to testing yet?

GiteaMirror commented

2026-05-21 01:52:13 -05:00

@MenceyBentayga commented on GitHub (Mar 15, 2026):

@MenceyBentayga any chance you got around to testing yet?

Hello! I though I had seen a response saying that someone else had tested it and it wasn't working, so I didn't try it myself.

Now, I look and this thread and that response is nowhere? Maybe the user deleted it. I will test myself tonight, in that case.

@MenceyBentayga commented on GitHub (Mar 15, 2026): > [@MenceyBentayga](https://github.com/MenceyBentayga) any chance you got around to testing yet? Hello! I though I had seen a response saying that someone else had tested it and it wasn't working, so I didn't try it myself. Now, I look and this thread and that response is nowhere? Maybe the user deleted it. I will test myself tonight, in that case.

GiteaMirror commented

2026-05-21 01:52:14 -05:00

@MenceyBentayga commented on GitHub (Mar 15, 2026):

Tried on 0.8.5 merging that pull request. Sadly, it doesn't seem to work.

@MenceyBentayga commented on GitHub (Mar 15, 2026): <img width="1042" height="533" alt="Image" src="https://github.com/user-attachments/assets/1a543041-8d09-4619-9fb2-9021ce2c7619" /> <img width="1196" height="459" alt="Image" src="https://github.com/user-attachments/assets/a0a4fb9b-d135-4096-8506-7495352cf7c1" /> Tried on 0.8.5 merging that pull request. Sadly, it doesn't seem to work.

GiteaMirror commented

2026-05-21 01:52:15 -05:00

@Classic298 commented on GitHub (Mar 15, 2026):

Thanks. Closing that pr.

@Classic298 commented on GitHub (Mar 15, 2026): Thanks. Closing that pr.

GiteaMirror commented

2026-05-21 01:52:16 -05:00

@eniraa commented on GitHub (Mar 17, 2026):

Would appreciate if someone could take a look at my pull request (#22773), which only fixes message editing functionality. I'm happy to make any changes needed to get this merged.

@eniraa commented on GitHub (Mar 17, 2026): Would appreciate if someone could take a look at my pull request (#22773), which only fixes message editing functionality. I'm happy to make any changes needed to get this merged.

GiteaMirror commented

2026-05-21 01:52:18 -05:00

@MenceyBentayga commented on GitHub (Mar 17, 2026):

Would appreciate if someone could take a look at my pull request (#22773), which only fixes message editing functionality. I'm happy to make any changes needed to get this merged.

LGTM!

@MenceyBentayga commented on GitHub (Mar 17, 2026): > Would appreciate if someone could take a look at my pull request ([#22773](https://github.com/open-webui/open-webui/pull/22773)), which only fixes message editing functionality. I'm happy to make any changes needed to get this merged. <img width="1623" height="871" alt="Image" src="https://github.com/user-attachments/assets/1c3a8d4e-f109-49a3-95e0-9b71c0bcf4c4" /> LGTM!

GiteaMirror commented

2026-05-21 01:52:18 -05:00

@frenzybiscuit commented on GitHub (Mar 26, 2026):

Hello,

This is still an issue in 0.8.11. In addition, regenerations don't work properly either. The first time you regenerate the LLM will mix context and get confused. The -second- time you regenerate, it works fine.

@frenzybiscuit commented on GitHub (Mar 26, 2026): Hello, This is still an issue in 0.8.11. In addition, regenerations don't work properly either. The first time you regenerate the LLM will mix context and get confused. The -second- time you regenerate, it works fine.

GiteaMirror commented

2026-05-21 01:52:19 -05:00

@syndicatedshannon commented on GitHub (Mar 30, 2026):

I briefly attempted to verify this fix, but still saw the issue I believe this is intended to resolve. The edit appears to be completed, but then is undone when continuing any further operation.

Initial question:

Edit, deleting "Paris."

Then press "Continue":

Alternately edit, replacing "Paris" with "Rome":

Then press "Continue":

I didn't trace exactly what is happening, but based on the responses it seems to receive an amalgam of both the original and edited content.

Regarding the portion of the reported defect above that says "Continue" shouldn't produce any further text once it completes, that isn't my understanding of the "Continue" feature. My understanding is that if the model generates an end token, that make be the apparent outcome, but it is not a guarantee. Continue may be used to give the assistant another opportunity to generate a token besides an end token. My understanding may be wrong.

Specifically, I tested the OCI image I understand would be built by the PR, using the following:

docker build --no-cache -t open-webui-pr22773 https://github.com/eniraa/open-webui.git#dev

@syndicatedshannon commented on GitHub (Mar 30, 2026): I briefly attempted to verify this fix, but still saw the issue I believe this is intended to resolve. The edit appears to be completed, but then is undone when continuing any further operation. Initial question: <img width="521" height="298" alt="Image" src="https://github.com/user-attachments/assets/f6949f18-b261-4b56-b797-df0ade51a7e4" /> Edit, deleting "Paris." <img width="506" height="282" alt="Image" src="https://github.com/user-attachments/assets/50db67ff-8835-476f-9df0-00fcf348a069" /> Then press "Continue": <img width="495" height="231" alt="Image" src="https://github.com/user-attachments/assets/45cbb062-5cf3-4e5a-a419-3f751a70de4a" /> Alternately edit, replacing "Paris" with "Rome": <img width="507" height="234" alt="Image" src="https://github.com/user-attachments/assets/41d4c3c0-e3aa-4772-b5e6-9ba6a3fc8009" /> Then press "Continue": <img width="504" height="308" alt="Image" src="https://github.com/user-attachments/assets/ecab8957-d0cb-4ac5-bb3f-b12223c02f37" /> I didn't trace exactly what is happening, but based on the responses it seems to receive an amalgam of both the original and edited content. Regarding the portion of the reported defect above that says "Continue" shouldn't produce any further text once it completes, that isn't my understanding of the "Continue" feature. My understanding is that if the model generates an end token, that make be the apparent outcome, but it is not a guarantee. Continue may be used to give the assistant another opportunity to generate a token besides an end token. My understanding may be wrong. Specifically, I tested the OCI image I understand would be built by the PR, using the following: `docker build --no-cache -t open-webui-pr22773 https://github.com/eniraa/open-webui.git#dev`

GiteaMirror commented

2026-05-21 01:52:20 -05:00

@eniraa commented on GitHub (Mar 31, 2026):

Thanks for taking a look into the continuation functionality. My current fix only addresses the edit not working properly, but I'll take a crack at the continue issue once I have more time.

@eniraa commented on GitHub (Mar 31, 2026): Thanks for taking a look into the continuation functionality. My current fix only addresses the edit not working properly, but I'll take a crack at the continue issue once I have more time.

GiteaMirror commented

2026-05-21 01:52:21 -05:00

@syndicatedshannon commented on GitHub (Mar 31, 2026):

Thanks @eniraa . I apologize I misunderstood the PR (and maybe the issue) and I see that edit by itself appears to work correctly. When I edit and then submit a new user turn e.g. "Please repeat your last response verbatim.", I get the assistant response I'd expect.

@syndicatedshannon commented on GitHub (Mar 31, 2026): Thanks @eniraa . I apologize I misunderstood the PR (and maybe the issue) and I see that edit by itself appears to work correctly. When I edit and then submit a new user turn e.g. "Please repeat your last response verbatim.", I get the assistant response I'd expect.

GiteaMirror commented

2026-05-21 01:52:23 -05:00

@syndicatedshannon commented on GitHub (Mar 31, 2026):

also, I noticed that the behavior is different when streaming is enabled vs. disabled. When disabled, just the continuation is left in the assistant response (too little text). When enabled, the result above (too much text) is seen.

Afterwards (in both cases), the client sends the "api/chat/completed" text displayed in the UI, which then persists after refresh. Seems sus to me, but is probably a separate issue, if not intended.

@eniraa

@syndicatedshannon commented on GitHub (Mar 31, 2026): also, I noticed that the behavior is different when streaming is enabled vs. disabled. When disabled, just the continuation is left in the assistant response (too little text). When enabled, the result above (too much text) is seen. Afterwards (in both cases), the client sends the "api/chat/completed" text displayed in the UI, which then persists after refresh. Seems sus to me, but is probably a separate issue, if not intended. @eniraa

GiteaMirror commented

2026-05-21 01:52:25 -05:00

@YashasviMantha commented on GitHub (Apr 4, 2026):

Still broken. I am on v0.8.12

@YashasviMantha commented on GitHub (Apr 4, 2026): Still broken. I am on v0.8.12

GiteaMirror commented

2026-05-21 01:52:26 -05:00

@dathbe commented on GitHub (Apr 14, 2026):

Possibly a related issue (if not, let me know and I'll open another Issue). When I use Open-WebUI to edit an image, it will work fine. But if I ask it to "regenerate", it will lose all context and give me a text response. It's not yet clear to me whether it is dropping the uploaded image or unticking the "image" integration, but either way regenerate fails.

Running 0.8.12 via Docker ghcr.io/open-webui/open-webui:ollama

Update: I get the same issue when I try to create image (not using an input image), so the problem seems to be with the "image" integration getting unticked for the regenerate stage.

@dathbe commented on GitHub (Apr 14, 2026): Possibly a related issue (if not, let me know and I'll open another Issue). When I use Open-WebUI to edit an image, it will work fine. But if I ask it to "regenerate", it will lose all context and give me a text response. It's not yet clear to me whether it is dropping the uploaded image or unticking the "image" integration, but either way regenerate fails. Running 0.8.12 via Docker ghcr.io/open-webui/open-webui:ollama Update: I get the same issue when I try to create image (not using an input image), so the problem seems to be with the "image" integration getting unticked for the regenerate stage.

GiteaMirror commented

2026-05-21 01:52:26 -05:00

@CookSleep commented on GitHub (Apr 17, 2026):

In version 0.8.12, even after editing a model's response, sending a new message still results in the model seeing the old version. This issue is really frustrating me 😭

@CookSleep commented on GitHub (Apr 17, 2026): In version 0.8.12, even after editing a model's response, sending a new message still results in the model seeing the old version. This issue is really frustrating me 😭

GiteaMirror commented

2026-05-21 01:52:27 -05:00

@MenceyBentayga commented on GitHub (Apr 21, 2026):

Given the branch has been merged, can someone confirm the behaviour for both edits and continuations is as expected in 0.9.0?

@MenceyBentayga commented on GitHub (Apr 21, 2026): Given the branch has been merged, can someone confirm the behaviour for both edits and continuations is as expected in 0.9.0?

GiteaMirror commented

2026-05-21 01:52:28 -05:00

@superjamie commented on GitHub (Apr 21, 2026):

This is not fixed in v0.9.0.

Looking at the actual response in the llama-swap Activity tab, Open-WebUI is still sending the full previous response to the backend OpenAI server, not the new edited short response.

(i am still running v0.7.2 as a workaround. this is fine for me)

@superjamie commented on GitHub (Apr 21, 2026): This is not fixed in v0.9.0. Looking at the actual response in the llama-swap Activity tab, Open-WebUI is still sending the full previous response to the backend OpenAI server, not the new edited short response. (i am still running v0.7.2 as a workaround. this is fine for me)

GiteaMirror commented

2026-05-21 01:52:29 -05:00

@taroxd commented on GitHub (Apr 26, 2026):

Not fixed in 0.9.2. When I want to modify the original message directly in SQLite DB, I find that the message edited in the webpage seems not being saved to DB.

My workaround is exporting the chat as json, removing the original content and importing it back. The removal is done by an AI-written python script.

#!/usr/bin/env python3
"""
Remove heavy message fields from Open WebUI export JSON.

This script removes `output` and `originalContent` from message objects
under any `messages` collection in the JSON structure.
"""

from __future__ import annotations

import argparse
import json
from pathlib import Path
from typing import Any


TARGET_FIELDS = ("output", "originalContent")


def strip_fields_from_message(message: dict[str, Any]) -> int:
    removed = 0
    for field in TARGET_FIELDS:
        if field in message:
            del message[field]
            removed += 1
    return removed


def walk_and_strip(node: Any) -> int:
    removed = 0

    if isinstance(node, dict):
        for key, value in list(node.items()):
            if key == "messages":
                if isinstance(value, list):
                    for item in value:
                        if isinstance(item, dict):
                            removed += strip_fields_from_message(item)
                elif isinstance(value, dict):
                    for item in value.values():
                        if isinstance(item, dict):
                            removed += strip_fields_from_message(item)

            removed += walk_and_strip(value)

    elif isinstance(node, list):
        for item in node:
            removed += walk_and_strip(item)

    return removed


def parse_args() -> argparse.Namespace:
    parser = argparse.ArgumentParser(
        description=(
            "Remove `output` and `originalContent` from Open WebUI message nodes."
        )
    )
    parser.add_argument("input", help="Path to Open WebUI export JSON")
    parser.add_argument(
        "-o",
        "--output",
        help="Path for cleaned JSON. If omitted, uses <input>.cleaned.json",
    )
    parser.add_argument(
        "--in-place",
        action="store_true",
        help="Overwrite input file directly",
    )
    parser.add_argument(
        "--pretty",
        action="store_true",
        help="Pretty-print output JSON with indentation",
    )
    return parser.parse_args()


def main() -> None:
    args = parse_args()
    input_path = Path(args.input)

    if not input_path.exists():
        raise FileNotFoundError(f"Input file does not exist: {input_path}")

    if args.in_place and args.output:
        raise ValueError("Use either --in-place or --output, not both")

    if args.in_place:
        output_path = input_path
    elif args.output:
        output_path = Path(args.output)
    else:
        output_path = input_path.with_name(f"{input_path.stem}.cleaned{input_path.suffix}")

    with input_path.open("r", encoding="utf-8") as f:
        data = json.load(f)

    removed_count = walk_and_strip(data)

    dump_kwargs: dict[str, Any]
    if args.pretty:
        dump_kwargs = {"ensure_ascii": False, "indent": 2}
    else:
        dump_kwargs = {"ensure_ascii": False, "separators": (",", ":")}

    with output_path.open("w", encoding="utf-8", newline="\n") as f:
        json.dump(data, f, **dump_kwargs)
        f.write("\n")

    print(f"Done. Removed {removed_count} field(s).")
    print(f"Output: {output_path}")


if __name__ == "__main__":
    main()

@taroxd commented on GitHub (Apr 26, 2026): Not fixed in 0.9.2. When I want to modify the original message directly in SQLite DB, I find that the message edited in the webpage seems not being saved to DB. My workaround is exporting the chat as json, removing the original content and importing it back. The removal is done by an AI-written python script. ```python #!/usr/bin/env python3 """ Remove heavy message fields from Open WebUI export JSON. This script removes `output` and `originalContent` from message objects under any `messages` collection in the JSON structure. """ from __future__ import annotations import argparse import json from pathlib import Path from typing import Any TARGET_FIELDS = ("output", "originalContent") def strip_fields_from_message(message: dict[str, Any]) -> int: removed = 0 for field in TARGET_FIELDS: if field in message: del message[field] removed += 1 return removed def walk_and_strip(node: Any) -> int: removed = 0 if isinstance(node, dict): for key, value in list(node.items()): if key == "messages": if isinstance(value, list): for item in value: if isinstance(item, dict): removed += strip_fields_from_message(item) elif isinstance(value, dict): for item in value.values(): if isinstance(item, dict): removed += strip_fields_from_message(item) removed += walk_and_strip(value) elif isinstance(node, list): for item in node: removed += walk_and_strip(item) return removed def parse_args() -> argparse.Namespace: parser = argparse.ArgumentParser( description=( "Remove `output` and `originalContent` from Open WebUI message nodes." ) ) parser.add_argument("input", help="Path to Open WebUI export JSON") parser.add_argument( "-o", "--output", help="Path for cleaned JSON. If omitted, uses <input>.cleaned.json", ) parser.add_argument( "--in-place", action="store_true", help="Overwrite input file directly", ) parser.add_argument( "--pretty", action="store_true", help="Pretty-print output JSON with indentation", ) return parser.parse_args() def main() -> None: args = parse_args() input_path = Path(args.input) if not input_path.exists(): raise FileNotFoundError(f"Input file does not exist: {input_path}") if args.in_place and args.output: raise ValueError("Use either --in-place or --output, not both") if args.in_place: output_path = input_path elif args.output: output_path = Path(args.output) else: output_path = input_path.with_name(f"{input_path.stem}.cleaned{input_path.suffix}") with input_path.open("r", encoding="utf-8") as f: data = json.load(f) removed_count = walk_and_strip(data) dump_kwargs: dict[str, Any] if args.pretty: dump_kwargs = {"ensure_ascii": False, "indent": 2} else: dump_kwargs = {"ensure_ascii": False, "separators": (",", ":")} with output_path.open("w", encoding="utf-8", newline="\n") as f: json.dump(data, f, **dump_kwargs) f.write("\n") print(f"Done. Removed {removed_count} field(s).") print(f"Output: {output_path}") if __name__ == "__main__": main() ```

GiteaMirror commented

2026-05-21 01:52:30 -05:00

@santiagozky commented on GitHub (Apr 27, 2026):

My python knowledge is limited. I found that when editing a response, the chat endpoint (update_chat_by_id ) is called, which updates a whole json into the chat table, but the chat_message table, which includes individual messages, does not seem to be updated at all. There is a function update_chat_message_by_id, but that does not seem to be called anywhere in the code
What I could not figure out is where the content that is send to the LLM is taken from. I assume it is from the chat_messages but I could not locate it. maybe someone can clarify why the chat content is duplicated in the database (a full json in chat and individual messages in chat_message). are both needed? I went through the old code and I could not figure it out either

(I mistakenly exposed a private url in a now deleted post).

@santiagozky commented on GitHub (Apr 27, 2026): My python knowledge is limited. I found that when editing a response, the chat endpoint (_update_chat_by_id_ ) is called, which updates a whole json into the chat table, but the chat_message table, which includes individual messages, does not seem to be updated at all. There is a function _update_chat_message_by_id_, but that does not seem to be called anywhere in the code What I could not figure out is where the content that is send to the LLM is taken from. I assume it is from the chat_messages but I could not locate it. maybe someone can clarify why the chat content is duplicated in the database (a full json in chat and individual messages in chat_message). are both needed? I went through the old code and I could not figure it out either (I mistakenly exposed a private url in a now deleted post).

GiteaMirror commented

2026-05-21 01:52:30 -05:00

@WuRunBear commented on GitHub (Apr 29, 2026):

async def update_chat_by_id(self, id: str, chat: dict, db: Optional[AsyncSession] = None) -> Optional[ChatModel]:
    try:
        async with get_async_db_context(db) as db:
            chat_item = await db.get(Chat, id)
            messages = chat.get('messages')
            if isinstance(messages, list) and messages:
                history = chat.get('history')
                if not isinstance(history, dict):
                    history = {}
                    chat['history'] = history

                history_messages = history.get('messages')
                if not isinstance(history_messages, dict):
                    history_messages = {}
                    history['messages'] = history_messages

                for assistant_message in messages:
                    if not isinstance(assistant_message, dict) or assistant_message.get('role') != 'assistant':
                        continue

                    assistant_content = assistant_message.get('content')
                    output_items = assistant_message.get('output')
                    if isinstance(output_items, list):
                        for output_item in output_items:
                            if not isinstance(output_item, dict) or output_item.get('type') != 'message':
                                continue
                            content_parts = output_item.get('content')
                            if not isinstance(content_parts, list):
                                continue
                            for content_part in content_parts:
                                if (
                                    isinstance(content_part, dict)
                                    and content_part.get('type') == 'output_text'
                                    and assistant_content is not None
                                ):
                                    content_part['text'] = assistant_content

                    message_id = assistant_message.get('id')
                    if message_id:
                        history_messages[message_id] = assistant_message

            chat_item.chat = self._clean_null_bytes(chat)
            chat_item.title = self._clean_null_bytes(chat['title']) if 'title' in chat else 'New Chat'

            chat_item.updated_at = int(time.time())

            await db.commit()

            return ChatModel.model_validate(chat_item)
    except Exception:
        return None

这个bug一直没有被修复，如果有人急需edit的功能，可以尝试替换update_chat_by_id的代码，可以临时解决无法edit的问题，只要后续更新时，把这部分代码覆盖掉就好
但是这可能会影响其他功能正常运行，不过对我没啥影响，哈哈哈

@WuRunBear commented on GitHub (Apr 29, 2026): async def update_chat_by_id(self, id: str, chat: dict, db: Optional[AsyncSession] = None) -> Optional[ChatModel]: try: async with get_async_db_context(db) as db: chat_item = await db.get(Chat, id) messages = chat.get('messages') if isinstance(messages, list) and messages: history = chat.get('history') if not isinstance(history, dict): history = {} chat['history'] = history history_messages = history.get('messages') if not isinstance(history_messages, dict): history_messages = {} history['messages'] = history_messages for assistant_message in messages: if not isinstance(assistant_message, dict) or assistant_message.get('role') != 'assistant': continue assistant_content = assistant_message.get('content') output_items = assistant_message.get('output') if isinstance(output_items, list): for output_item in output_items: if not isinstance(output_item, dict) or output_item.get('type') != 'message': continue content_parts = output_item.get('content') if not isinstance(content_parts, list): continue for content_part in content_parts: if ( isinstance(content_part, dict) and content_part.get('type') == 'output_text' and assistant_content is not None ): content_part['text'] = assistant_content message_id = assistant_message.get('id') if message_id: history_messages[message_id] = assistant_message chat_item.chat = self._clean_null_bytes(chat) chat_item.title = self._clean_null_bytes(chat['title']) if 'title' in chat else 'New Chat' chat_item.updated_at = int(time.time()) await db.commit() return ChatModel.model_validate(chat_item) except Exception: return None 这个bug一直没有被修复，如果有人急需edit的功能，可以尝试替换update_chat_by_id的代码，可以临时解决无法edit的问题，只要后续更新时，把这部分代码覆盖掉就好但是这可能会影响其他功能正常运行，不过对我没啥影响，哈哈哈

GiteaMirror commented

2026-05-21 01:52:31 -05:00

@tjbck commented on GitHub (May 9, 2026):

Addressed in dev!

@tjbck commented on GitHub (May 9, 2026): Addressed in dev!

GiteaMirror commented

2026-05-21 01:52:32 -05:00

@ryankrage77 commented on GitHub (May 9, 2026):

v0.9.4 now clears the response and starts over rather than editing.

EDIT: After some further testing, looks like editing does work when the response is allowed to finish generating first. Stopping it early, editing and trying to continue causes the response to be replaced. Seems to only affect the first message in a conversation, editing subsequent replies works as expected.

@ryankrage77 commented on GitHub (May 9, 2026): v0.9.4 now clears the response and starts over rather than editing. EDIT: After some further testing, looks like editing does work when the response is allowed to finish generating first. Stopping it early, editing and trying to continue causes the response to be replaced. Seems to only affect the first message in a conversation, editing subsequent replies works as expected.

GiteaMirror commented

2026-05-21 01:52:32 -05:00

@Ghosthree3 commented on GitHub (May 10, 2026):

It can be very wasteful (both of resources and time) to let the response finish if I already know I want to edit it. But if it's only the first message, and subsequent messages can be stopped early and edited, I guess that's an acceptable state for things to be given the current problem. It did used to just work for every message, at any time, all the time.

@Ghosthree3 commented on GitHub (May 10, 2026): It can be very wasteful (both of resources and time) to let the response finish if I already know I want to edit it. But if it's only the first message, and subsequent messages can be stopped early and edited, I guess that's an acceptable state for things to be given the current problem. It did used to just work for every message, at any time, all the time.

GiteaMirror commented

2026-05-21 01:52:33 -05:00

@StrykeSlammerII commented on GitHub (May 11, 2026):

EDIT: After some further testing, looks like editing does work when the response is allowed to finish generating first. Stopping it early, editing and trying to continue causes the response to be replaced. Seems to only affect the first message in a conversation, editing subsequent replies works as expected.

My testing had this occur mid-conversation, but that may be because I restarted the LLM or switched conversations and came back later. Thanks for sharing something to watch for.

I miss the original behavior, of course, but the current fix is much better than the workaround.

@StrykeSlammerII commented on GitHub (May 11, 2026): > EDIT: After some further testing, looks like editing does work when the response is allowed to finish generating first. Stopping it early, editing and trying to continue causes the response to be replaced. Seems to only affect the first message in a conversation, editing subsequent replies works as expected. My testing had this occur mid-conversation, but that may be because I restarted the LLM or switched conversations and came back later. Thanks for sharing something to watch for. I miss the original behavior, of course, but the current fix is much better than the workaround.

GiteaMirror commented

2026-05-21 01:52:34 -05:00

@StrykeSlammerII commented on GitHub (May 11, 2026):

Update: There's still something off with this fix.
I regularly make edits to LLM resopnses. The edits now appear to stick, but several minutes later if I scroll up to the start of the conversation, it shows the unedited version again.
I haven't dug into what is getting sent as the prompt or when it changes.

Just noting this for anyone following the issue. I'll look for a new issue for this problem--or make one myself if I can find specific steps to replicate.

@StrykeSlammerII commented on GitHub (May 11, 2026): Update: There's still _something_ off with this fix. I regularly make edits to LLM resopnses. The edits now appear to stick, but several minutes later if I scroll up to the start of the conversation, it shows the unedited version again. I haven't dug into what is getting sent as the prompt or when it changes. Just noting this for anyone following the issue. I'll look for a new issue for this problem--or make one myself if I can find specific steps to replicate.

GiteaMirror commented

2026-05-21 01:52:35 -05:00

@Ghosthree3 commented on GitHub (May 20, 2026):

After more testing I've noticed three annoying issues.

The first is that I don't seem to be able to edit a response until it has completed at least one time. If I attempt to do so, clicking continue response acts as if I've clicked regenerate, but without making a conversation fork, rewriting the response from scratch and ignoring the edit entirely.

The second is that when clicking edit (after completing at least one response so it works), the edit window contains whatever changes I last saved. ie. if I make an edit then hit continue response, stop it, and click edit again, the editor will show my previous edit without including any of the newly generated text. This means that in order to incorporate the new text I have to manually copy new output into the editor to update it (which also drops formatting). This only changes if I let the response complete.
This is much worse than the first, which at least only makes me waste a few minutes letting a response generate before I can move on to editing it.

The third is far less important as it doesn't actually affect workflow but is still a bug. When making an edit and hitting save, the edit is indeed saved and will be used if I continue the response, but the response outside of the edit window is not updated until I do.

EDIT: I should note that there is some inconsistency with the misbehavior mentioned above, but I can't tell you why just yet.

EDIT2: Ok, additionally I'm finding that sometimes edits are being reverted. Not immediately, but some time later when I stop paying attention. I believe it's caused by editing a response older than the most recent one then regenerating a later response. I think I can force the edit to 'save' by creating a new prompt fork from the edited response then deleting it.

@Ghosthree3 commented on GitHub (May 20, 2026): After more testing I've noticed three annoying issues. The first is that I don't seem to be able to edit a response until it has completed at least one time. If I attempt to do so, clicking continue response acts as if I've clicked regenerate, but without making a conversation fork, rewriting the response from scratch and ignoring the edit entirely. The second is that when clicking edit (after completing at least one response so it works), the edit window contains whatever changes I last saved. ie. if I make an edit then hit continue response, stop it, and click edit again, the editor will show my previous edit without including any of the newly generated text. This means that in order to incorporate the new text I have to manually copy new output into the editor to update it (which also drops formatting). This only changes if I let the response complete. This is much worse than the first, which at least only makes me waste a few minutes letting a response generate before I can move on to editing it. The third is far less important as it doesn't actually affect workflow but is still a bug. When making an edit and hitting save, the edit is indeed saved and will be used if I continue the response, but the response outside of the edit window is not updated until I do. EDIT: I should note that there is some inconsistency with the misbehavior mentioned above, but I can't tell you why just yet. EDIT2: Ok, additionally I'm finding that sometimes edits are being reverted. Not immediately, but some time later when I stop paying attention. I believe it's caused by editing a response older than the most recent one then regenerating a later response. I think I can force the edit to 'save' by creating a new prompt fork from the edited response then deleting it.

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