github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-16 23:21:44 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #24559] issue: "Not enough data to satisfy transfer length header." error interrupts responses #107327

New Issue
Open
opened 2026-05-18 06:06:44 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-05-18 06:06:44 -05:00
Owner
Copy Link

Originally created by @andscape-dev on GitHub (May 11, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24559

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

v0.9.5

Ollama Version (if applicable)

No response

Operating System

MacOS Sonoma

Browser (if applicable)

Zen Browser 1.19.12b (Firefox 150.0.2) (aarch64)

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

I submit a prompt, the response starts generating and completes successfully.

Actual Behavior

The response continues for a variable amount of tokens before interrupting with the following UI error:

Response payload is not completed: <TransferEncodingError: 400, message='Not enough data to satisfy transfer length header.'>

Re-generating the response incurs in the same error. The logs show a similar error:

ERROR    | open_webui.main:process_chat:2013 - Error processing chat payload: Response payload is not completed: <TransferEncodingError: 400, message='Not enough data to satisfy transfer length header.'>

Just once, no other relevant error log can be found around it.

Steps to Reproduce

Details:

  • Replicated with v0.9.3, v0.9.4, and v0.9.5. I don't have a backup for pre-v0.9.3 so I can't rollback the breaking release with DB migrations.
  • Using a custom agent based on GLM-5.1 from Z.ai (open.bigmodel.cn OpenAI-compatble endpoint), with streaming and native function calling enabled.
  • It usually starts happening after the first couple of prompts in a chat, with 20/30k tokens of context including multiple tool calls. Failing responses do start, generate a few lines of output, then drop.

Logs & Screenshots

UI error:

Image

Logs snippet, redacted:

2026-05-11T02:52:18.708990072+02:00 2026-05-11 02:52:18.708 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-05-11T02:53:19.340890117+02:00 2026-05-11 02:53:19.340 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-05-11T02:53:44.424531037+02:00 2026-05-11 02:53:44.424 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "POST /api/chat/completions HTTP/1.1" 200
2026-05-11T02:53:44.485731402+02:00 2026-05-11 02:53:44.485 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "POST /api/v1/chats/<UUID> HTTP/1.1" 200
2026-05-11T02:53:44.503369741+02:00 2026-05-11 02:53:44.503 | WARNING  | open_webui.utils.oauth:get_oauth_token:1083 - No OAuth session found for user <UUID>, session <UUID>
2026-05-11T02:53:45.025611812+02:00 2026-05-11 02:53:45.025 | INFO     | httpx._client:_send_single_request:1740 - HTTP Request: POST https://mcp.context7.com/mcp "HTTP/1.1 200 OK"
2026-05-11T02:53:45.027057132+02:00 2026-05-11 02:53:45.026 | INFO     | mcp.client.streamable_http:_maybe_extract_protocol_version_from_message:193 - Negotiated protocol version: 2025-11-25
2026-05-11T02:53:45.486943362+02:00 2026-05-11 02:53:45.486 | INFO     | httpx._client:_send_single_request:1740 - HTTP Request: POST https://mcp.context7.com/mcp "HTTP/1.1 202 Accepted"
2026-05-11T02:53:45.967057225+02:00 2026-05-11 02:53:45.966 | INFO     | httpx._client:_send_single_request:1740 - HTTP Request: POST https://mcp.context7.com/mcp "HTTP/1.1 200 OK"
2026-05-11T02:53:45.994970674+02:00 2026-05-11 02:53:45.994 | INFO     | open_webui.utils.plugin:install_frontmatter_requirements:417 - No requirements found in frontmatter.
2026-05-11T02:53:46.053331947+02:00 2026-05-11 02:53:46.053 | INFO     | open_webui.utils.plugin:load_tool_module_by_id:233 - Loaded module: tool_sub_agent
2026-05-11T02:53:46.120912733+02:00 2026-05-11 02:53:46.120 | INFO     | open_webui.utils.session_pool:get_session:66 - Created shared aiohttp session pool (limit=unlimited, per_host=unlimited, dns_ttl=300)
2026-05-11T02:53:54.461580573+02:00 2026-05-11 02:53:54.459 | WARNING  | open_webui.utils.oauth:get_oauth_token:1083 - No OAuth session found for user <UUID>, session <UUID>
2026-05-11T02:54:17.014810840+02:00 2026-05-11 02:54:17.014 | ERROR    | open_webui.main:process_chat:2013 - Error processing chat payload: Response payload is not completed: <TransferEncodingError: 400, message='Not enough data to satisfy transfer length header.'>
2026-05-11T02:54:19.353696361+02:00 2026-05-11 02:54:19.353 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-05-11T02:55:20.073639226+02:00 2026-05-11 02:55:20.073 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-05-11T02:56:20.559030400+02:00 2026-05-11 02:56:20.558 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304
2026-05-11T02:57:20.873094478+02:00 2026-05-11 02:57:20.872 | INFO     | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304

Additional Information

The failures don't seem deterministic, so could be provider instability causing connections to drop, but I can use the same provider just fine with the same subscription on other clients.

Originally created by @andscape-dev on GitHub (May 11, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24559 ### 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 v0.9.5 ### Ollama Version (if applicable) _No response_ ### Operating System MacOS Sonoma ### Browser (if applicable) Zen Browser 1.19.12b (Firefox 150.0.2) (aarch64) ### 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 I submit a prompt, the response starts generating and completes successfully. ### Actual Behavior The response continues for a variable amount of tokens before interrupting with the following UI error: ```text Response payload is not completed: <TransferEncodingError: 400, message='Not enough data to satisfy transfer length header.'> ``` Re-generating the response incurs in the same error. The logs show a similar error: ```text ERROR | open_webui.main:process_chat:2013 - Error processing chat payload: Response payload is not completed: <TransferEncodingError: 400, message='Not enough data to satisfy transfer length header.'> ``` Just once, no other relevant error log can be found around it. ### Steps to Reproduce Details: - Replicated with v0.9.3, v0.9.4, and v0.9.5. I don't have a backup for pre-v0.9.3 so I can't rollback the breaking release with DB migrations. - Using a custom agent based on GLM-5.1 from Z.ai (`open.bigmodel.cn` OpenAI-compatble endpoint), with streaming and native function calling enabled. - It usually starts happening after the first couple of prompts in a chat, with 20/30k tokens of context including multiple tool calls. Failing responses do start, generate a few lines of output, then drop. ### Logs & Screenshots UI error: <img width="945" height="95" alt="Image" src="https://github.com/user-attachments/assets/998c4e9e-bd2b-41ec-b0b7-7a52dd9ce6f6" /> Logs snippet, redacted: ```text 2026-05-11T02:52:18.708990072+02:00 2026-05-11 02:52:18.708 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304 2026-05-11T02:53:19.340890117+02:00 2026-05-11 02:53:19.340 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304 2026-05-11T02:53:44.424531037+02:00 2026-05-11 02:53:44.424 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "POST /api/chat/completions HTTP/1.1" 200 2026-05-11T02:53:44.485731402+02:00 2026-05-11 02:53:44.485 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "POST /api/v1/chats/<UUID> HTTP/1.1" 200 2026-05-11T02:53:44.503369741+02:00 2026-05-11 02:53:44.503 | WARNING | open_webui.utils.oauth:get_oauth_token:1083 - No OAuth session found for user <UUID>, session <UUID> 2026-05-11T02:53:45.025611812+02:00 2026-05-11 02:53:45.025 | INFO | httpx._client:_send_single_request:1740 - HTTP Request: POST https://mcp.context7.com/mcp "HTTP/1.1 200 OK" 2026-05-11T02:53:45.027057132+02:00 2026-05-11 02:53:45.026 | INFO | mcp.client.streamable_http:_maybe_extract_protocol_version_from_message:193 - Negotiated protocol version: 2025-11-25 2026-05-11T02:53:45.486943362+02:00 2026-05-11 02:53:45.486 | INFO | httpx._client:_send_single_request:1740 - HTTP Request: POST https://mcp.context7.com/mcp "HTTP/1.1 202 Accepted" 2026-05-11T02:53:45.967057225+02:00 2026-05-11 02:53:45.966 | INFO | httpx._client:_send_single_request:1740 - HTTP Request: POST https://mcp.context7.com/mcp "HTTP/1.1 200 OK" 2026-05-11T02:53:45.994970674+02:00 2026-05-11 02:53:45.994 | INFO | open_webui.utils.plugin:install_frontmatter_requirements:417 - No requirements found in frontmatter. 2026-05-11T02:53:46.053331947+02:00 2026-05-11 02:53:46.053 | INFO | open_webui.utils.plugin:load_tool_module_by_id:233 - Loaded module: tool_sub_agent 2026-05-11T02:53:46.120912733+02:00 2026-05-11 02:53:46.120 | INFO | open_webui.utils.session_pool:get_session:66 - Created shared aiohttp session pool (limit=unlimited, per_host=unlimited, dns_ttl=300) 2026-05-11T02:53:54.461580573+02:00 2026-05-11 02:53:54.459 | WARNING | open_webui.utils.oauth:get_oauth_token:1083 - No OAuth session found for user <UUID>, session <UUID> 2026-05-11T02:54:17.014810840+02:00 2026-05-11 02:54:17.014 | ERROR | open_webui.main:process_chat:2013 - Error processing chat payload: Response payload is not completed: <TransferEncodingError: 400, message='Not enough data to satisfy transfer length header.'> 2026-05-11T02:54:19.353696361+02:00 2026-05-11 02:54:19.353 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304 2026-05-11T02:55:20.073639226+02:00 2026-05-11 02:55:20.073 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304 2026-05-11T02:56:20.559030400+02:00 2026-05-11 02:56:20.558 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304 2026-05-11T02:57:20.873094478+02:00 2026-05-11 02:57:20.872 | INFO | uvicorn.protocols.http.httptools_impl:send:483 - 10.42.2.1:0 - "GET /_app/version.json HTTP/1.1" 304 ``` ### Additional Information The failures don't seem deterministic, so could be provider instability causing connections to drop, but I can use the same provider just fine with the same subscription on other clients.
GiteaMirror added the bug label 2026-05-18 06:06:44 -05:00
GiteaMirror commented 2026-05-18 06:06:49 -05:00
Author
Owner
Copy Link

@owui-terminator[bot] commented on GitHub (May 11, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

  1. 🟣 #12021 issue: ClientPayloadError: Response payload is not completed: TransferEncodingError
    This issue reports the same aiohttp/TransferEncodingError message: 'Response payload is not completed: <TransferEncodingError... Not enough data to satisfy transfer length header.>' It appears to be the closest direct match to the error in the new report, though on an older version and a different upstream provider.
    by poonesh · bug

  2. 🟣 #13474 SSE streaming in Open WebUI API Endpoints (Chat Completions) fails to handle incomplete chunks
    This issue is about Open WebUI's streaming/chat-completions handling and incomplete SSE chunks. While the root cause differs, it is closely related to response streaming breakage in the same code path and may help if the new error is caused by truncated streamed responses.
    by hide212131 · bug

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

<!-- gh-comment-id:4416918302 --> @owui-terminator[bot] commented on GitHub (May 11, 2026): <!-- terminator-bot:related-issues-reply --> 🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟣 [#12021](https://github.com/open-webui/open-webui/issues/12021) **issue: ClientPayloadError: Response payload is not completed: TransferEncodingError** *This issue reports the same aiohttp/TransferEncodingError message: 'Response payload is not completed: <TransferEncodingError... Not enough data to satisfy transfer length header.>' It appears to be the closest direct match to the error in the new report, though on an older version and a different upstream provider.* *by poonesh · `bug`* 2. 🟣 [#13474](https://github.com/open-webui/open-webui/issues/13474) **SSE streaming in Open WebUI API Endpoints (Chat Completions) fails to handle incomplete chunks** *This issue is about Open WebUI's streaming/chat-completions handling and incomplete SSE chunks. While the root cause differs, it is closely related to response streaming breakage in the same code path and may help if the new error is caused by truncated streamed responses.* *by hide212131 · `bug`* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.
GiteaMirror commented 2026-05-18 06:06:49 -05:00
Author
Owner
Copy Link

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

This is likely not an error from open webui side. Can you reproduce it on older versions? This looks like an upstream error from the provider. This error message doesn't exist in open webui

<!-- gh-comment-id:4417873811 --> @Classic298 commented on GitHub (May 11, 2026): This is likely not an error from open webui side. Can you reproduce it on older versions? This looks like an upstream error from the provider. This error message doesn't exist in open webui
GiteaMirror commented 2026-05-18 06:06:50 -05:00
Author
Owner
Copy Link

@andscape-dev commented on GitHub (May 11, 2026):

As I said I don't have a backup for pre-v0.9.3, so I can't easily rollback further due to the breaking migrations in v0.9.3. I'm gonna try to set up a test instance with v0.9.2 as soon as I have the time.

The error is coming from aiohttp: https://github.com/aio-libs/aiohttp/issues/4630. It might be caused by an upstream provider error, but again I'm using the same provider with the same configuration from other clients without issue.

<!-- gh-comment-id:4418883324 --> @andscape-dev commented on GitHub (May 11, 2026): As I said I don't have a backup for pre-v0.9.3, so I can't easily rollback further due to the breaking migrations in v0.9.3. I'm gonna try to set up a test instance with v0.9.2 as soon as I have the time. The error is coming from `aiohttp`: https://github.com/aio-libs/aiohttp/issues/4630. It might be caused by an upstream provider error, but again I'm using the same provider with the same configuration from other clients without issue.
GiteaMirror commented 2026-05-18 06:06:51 -05:00
Author
Owner
Copy Link

@andscape-dev commented on GitHub (May 17, 2026):

I'm now convinced that AIOHTTP is not respecting the timeout setting, and dropping the connection mid-response stream after ~30s. I have the same behavior using models from self-hosted Ollama and in the Ollama logs there is no error, just a POST to "/api/chat" with duration of almost exactly 30s, every time. OpenWebUI is terminating the stream prematurely after 30s, and then interpreting the truncated stream as a malformed response. I have explicitly set AIOHTTP_CLIENT_TIMEOUT to hundreds of seconds, but the stream still gets terminated after 30. Setting it to '' for no timeout makes no difference.

<!-- gh-comment-id:4468692772 --> @andscape-dev commented on GitHub (May 17, 2026): I'm now convinced that AIOHTTP is not respecting the timeout setting, and dropping the connection mid-response stream after ~30s. I have the same behavior using models from self-hosted Ollama and in the Ollama logs there is no error, just a POST to "/api/chat" with duration of almost exactly 30s, every time. OpenWebUI is terminating the stream prematurely after 30s, and then interpreting the truncated stream as a malformed response. I have explicitly set `AIOHTTP_CLIENT_TIMEOUT` to hundreds of seconds, but the stream still gets terminated after 30. Setting it to `''` for no timeout makes no difference.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#107327
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?