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.2 (local checkout used for code inspection: 8dae237a0)
Ollama Version (if applicable)
N/A - image generation uses an OpenAI-compatible endpoint, not Ollama
Operating System
Docker/Linux backend; host observed from local diagnosis on macOS
Browser (if applicable)
N/A - backend/tool-call failure
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
Transport-level failures from an OpenAI-compatible image generation endpoint, such as aiohttp.ServerDisconnectedError, ClientConnectionError, ClientPayloadError, or timeouts, should not be reported to the user as HTTP 400.
These should be surfaced as a gateway/upstream failure, for example 502 or 504, with diagnostic logging that includes the image generation engine, target API base URL host, model, elapsed time, exception type, and whether the failure happened during request, response read, or image upload.
Actual Behavior
When using the built-in generate_image tool with an OpenAI-compatible image generation endpoint, Open WebUI sometimes returns:
400: [ERROR: Server disconnected]
The underlying exception is aiohttp.ServerDisconnectedError('Server disconnected'). This appears to be a transport/upstream disconnect, but image_generations() catches the exception and wraps it as HTTP 400, making it look like a bad request or invalid image-generation parameter.
Steps to Reproduce
Run Open WebUI with image generation enabled.
Configure image generation with engine=openai and an OpenAI-compatible API base URL.
Configure the image model as gpt-image-2.
Configure image size as auto.
Trigger the built-in generate_image tool from chat, for example with a normal portrait/image prompt.
Observe that the request is intermittent: it sometimes succeeds, but sometimes the upstream has already completed the image generation while Open WebUI returns 400: [ERROR: Server disconnected].
The corresponding OpenAI-compatible image request shape is:
The issue is not that this payload is always invalid. In local diagnostics, the same model/payload shape returned HTTP 200 with b64_json image data when sent directly with curl and with aiohttp==3.13.5. The confusing part is that an intermittent transport disconnect is surfaced as a user-facing HTTP 400.
Logs & Screenshots
Relevant stack trace:
File "/app/backend/open_webui/utils/tools.py", line 134, in new_function
return await partial_func(*args, **kwargs)
File "/app/backend/open_webui/tools/builtin.py", line 280, in generate_image
images = await image_generations(...)
File "/app/backend/open_webui/routers/images.py", line 771, in image_generations
raise HTTPException(status_code=400, detail=ERROR_MESSAGES.DEFAULT(error))
fastapi.exceptions.HTTPException: 400: [ERROR: Server disconnected]
This may be especially confusing with OpenAI-compatible proxy/CDN endpoints returning large chunked JSON responses containing b64_json image data. If the upstream has already generated the image and the connection drops while returning the response to Open WebUI, users may see a 400 even though the failure is not caused by invalid request parameters.
Possible improvement:
Handle aiohttp transport exceptions separately from ClientResponseError.
Map ServerDisconnectedError / ClientConnectionError / ClientPayloadError to 502.
Map timeout errors to 504.
Include exception type and elapsed time in server logs.
Consider avoiding keep-alive reuse or adding a narrowly scoped retry option for transient disconnects on OpenAI-compatible image generation requests.
Originally created by @belugaming on GitHub (Apr 30, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24265
### 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.2 (local checkout used for code inspection: 8dae237a0)
### Ollama Version (if applicable)
N/A - image generation uses an OpenAI-compatible endpoint, not Ollama
### Operating System
Docker/Linux backend; host observed from local diagnosis on macOS
### Browser (if applicable)
N/A - backend/tool-call failure
### 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
Transport-level failures from an OpenAI-compatible image generation endpoint, such as aiohttp.ServerDisconnectedError, ClientConnectionError, ClientPayloadError, or timeouts, should not be reported to the user as HTTP 400.
These should be surfaced as a gateway/upstream failure, for example 502 or 504, with diagnostic logging that includes the image generation engine, target API base URL host, model, elapsed time, exception type, and whether the failure happened during request, response read, or image upload.
### Actual Behavior
When using the built-in generate_image tool with an OpenAI-compatible image generation endpoint, Open WebUI sometimes returns:
400: [ERROR: Server disconnected]
The underlying exception is aiohttp.ServerDisconnectedError('Server disconnected'). This appears to be a transport/upstream disconnect, but image_generations() catches the exception and wraps it as HTTP 400, making it look like a bad request or invalid image-generation parameter.
### Steps to Reproduce
1. Run Open WebUI with image generation enabled.
2. Configure image generation with engine=openai and an OpenAI-compatible API base URL.
3. Configure the image model as gpt-image-2.
4. Configure image size as auto.
5. Trigger the built-in generate_image tool from chat, for example with a normal portrait/image prompt.
6. Observe that the request is intermittent: it sometimes succeeds, but sometimes the upstream has already completed the image generation while Open WebUI returns 400: [ERROR: Server disconnected].
The corresponding OpenAI-compatible image request shape is:
```json
{
"model": "gpt-image-2",
"prompt": "Diagnostic image generation prompt",
"n": 1,
"size": "auto"
}
```
The issue is not that this payload is always invalid. In local diagnostics, the same model/payload shape returned HTTP 200 with b64_json image data when sent directly with curl and with aiohttp==3.13.5. The confusing part is that an intermittent transport disconnect is surfaced as a user-facing HTTP 400.
### Logs & Screenshots
Relevant stack trace:
```text
File "/app/backend/open_webui/utils/tools.py", line 134, in new_function
return await partial_func(*args, **kwargs)
File "/app/backend/open_webui/tools/builtin.py", line 280, in generate_image
images = await image_generations(...)
File "/app/backend/open_webui/routers/images.py", line 771, in image_generations
raise HTTPException(status_code=400, detail=ERROR_MESSAGES.DEFAULT(error))
fastapi.exceptions.HTTPException: 400: [ERROR: Server disconnected]
```
Relevant code path:
```python
# backend/open_webui/routers/images.py
except Exception as e:
error = e
if isinstance(e, aiohttp.ClientResponseError):
error = e.message
raise HTTPException(status_code=400, detail=ERROR_MESSAGES.DEFAULT(error))
```
The inner exception shown in the logs is:
```text
aiohttp.ServerDisconnectedError('Server disconnected')
```
### Additional Information
This may be especially confusing with OpenAI-compatible proxy/CDN endpoints returning large chunked JSON responses containing b64_json image data. If the upstream has already generated the image and the connection drops while returning the response to Open WebUI, users may see a 400 even though the failure is not caused by invalid request parameters.
Possible improvement:
- Handle aiohttp transport exceptions separately from ClientResponseError.
- Map ServerDisconnectedError / ClientConnectionError / ClientPayloadError to 502.
- Map timeout errors to 504.
- Include exception type and elapsed time in server logs.
- Consider avoiding keep-alive reuse or adding a narrowly scoped retry option for transient disconnects on OpenAI-compatible image generation requests.
GiteaMirror
added the bug label 2026-05-21 02:52:33 -05:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @belugaming on GitHub (Apr 30, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24265
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.9.2 (local checkout used for code inspection:
8dae237a0)Ollama Version (if applicable)
N/A - image generation uses an OpenAI-compatible endpoint, not Ollama
Operating System
Docker/Linux backend; host observed from local diagnosis on macOS
Browser (if applicable)
N/A - backend/tool-call failure
Confirmation
README.md.Expected Behavior
Transport-level failures from an OpenAI-compatible image generation endpoint, such as aiohttp.ServerDisconnectedError, ClientConnectionError, ClientPayloadError, or timeouts, should not be reported to the user as HTTP 400.
These should be surfaced as a gateway/upstream failure, for example 502 or 504, with diagnostic logging that includes the image generation engine, target API base URL host, model, elapsed time, exception type, and whether the failure happened during request, response read, or image upload.
Actual Behavior
When using the built-in generate_image tool with an OpenAI-compatible image generation endpoint, Open WebUI sometimes returns:
400: [ERROR: Server disconnected]
The underlying exception is aiohttp.ServerDisconnectedError('Server disconnected'). This appears to be a transport/upstream disconnect, but image_generations() catches the exception and wraps it as HTTP 400, making it look like a bad request or invalid image-generation parameter.
Steps to Reproduce
The corresponding OpenAI-compatible image request shape is:
The issue is not that this payload is always invalid. In local diagnostics, the same model/payload shape returned HTTP 200 with b64_json image data when sent directly with curl and with aiohttp==3.13.5. The confusing part is that an intermittent transport disconnect is surfaced as a user-facing HTTP 400.
Logs & Screenshots
Relevant stack trace:
Relevant code path:
The inner exception shown in the logs is:
Additional Information
This may be especially confusing with OpenAI-compatible proxy/CDN endpoints returning large chunked JSON responses containing b64_json image data. If the upstream has already generated the image and the connection drops while returning the response to Open WebUI, users may see a 400 even though the failure is not caused by invalid request parameters.
Possible improvement: