issue: Chat is saved on every token, even with ENABLE_REALTIME_CHAT_SAVE set to FALSE #6183

New Issue

GiteaMirror · 2025-11-11T16:47:20-06:00

GiteaMirror commented

2025-11-11 16:47:20 -06:00

Originally created by @aleprj on GitHub (Aug 22, 2025).

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

0.6.25

Ollama Version (if applicable)

No response

Operating System

Windows 11

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 using a streming model, the chat should be saved in the database only after the full message is received, unless ENABLE_REALTIME_CHAT_SAVE is set to TRUE.

Actual Behavior

In multiple scenarios (for instance when using a custom pipe) the chat is saved to the database on every token received, even with ENABLE_REALTIME_CHAT_SAVE set to false.
It doesn't seem to be something bad, but I'm dealing with "large" files (actually a 3MB Excel file, I wouldn't call it large) and It makes the pipe unusable unless we turn off streaming.

Steps to Reproduce

1 - Make sure ENABLE_REALTIME_CHAT_SAVE is set to false
2 - Make a custom Function that uses streaming
3 - Start a chat in your custom modem
4 - Add a very large prompt (or a file)
5- Enjoy the slow motion streaming of the answer. Also, the whole system becomes slow for all users as a very large json is being updated in the database multiple times in a row.

Logs & Screenshots

No logs

Additional Information

I will be adding a PR to fix this. In my test it reduced the answer from ~300s to ~5s.

Originally created by @aleprj on GitHub (Aug 22, 2025). ### 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 0.6.25 ### Ollama Version (if applicable) _No response_ ### Operating System Windows 11 ### 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 using a streming model, the chat should be saved in the database only after the full message is received, unless ENABLE_REALTIME_CHAT_SAVE is set to TRUE. ### Actual Behavior In multiple scenarios (for instance when using a custom pipe) the chat is saved to the database on every token received, even with ENABLE_REALTIME_CHAT_SAVE set to false. It doesn't seem to be something bad, but I'm dealing with "large" files (actually a 3MB Excel file, I wouldn't call it large) and It makes the pipe unusable unless we turn off streaming. ### Steps to Reproduce 1 - Make sure ENABLE_REALTIME_CHAT_SAVE is set to false 2 - Make a custom Function that uses streaming 3 - Start a chat in your custom modem 4 - Add a very large prompt (or a file) 5- Enjoy the slow motion streaming of the answer. Also, the whole system becomes slow for all users as a very large json is being updated in the database multiple times in a row. ### Logs & Screenshots No logs ### Additional Information I will be adding a PR to fix this. In my test it reduced the answer from ~300s to ~5s.

GiteaMirror added the bug label 2025-11-11 16:47:20 -06:00

GiteaMirror closed this issue

2025-11-11 16:47:20 -06:00

GiteaMirror commented

2025-11-11 16:47:21 -06:00

@tjbck commented on GitHub (Aug 26, 2025):

You can techinically use chat:message:delta event instead of message, keep us updated.

@tjbck commented on GitHub (Aug 26, 2025): You can techinically use `chat:message:delta` event instead of `message`, keep us updated.

GiteaMirror referenced this issue

2026-04-19 20:41:09 -05:00

[GH-ISSUE #6183] Allow the possibility to block/allow/whitelist model parameters #14270

GiteaMirror referenced this issue