mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 10:58:17 -05:00
[GH-ISSUE #12276] issue: Premature file upload termination (Docling); 504 & JSON errors #16529
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#16529
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 @Infinnerty on GitHub (Apr 1, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/12276
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.6.0
Ollama Version (if applicable)
No response
Operating System
Ubuntu/k8s
Browser (if applicable)
Firefox 136.0.4
Confirmation
README.md.Expected Behavior
The OpenWebUI should:
Actual Behavior
The file upload disappears from the OpenWebUI interface during Docling processing. The browser console shows a 504 Gateway Timeout error and a JSON parsing error.
Steps to Reproduce
Logs & Screenshots
Docling Logs:
Browser Console Logs:
Additional Information
The issue persists across different file types.
The 504 error consistently appears, potentially as a result of OpenWebUI prematurely closing the connection.
The JSON parsing error could be a consequence of OpenWebUI attempting to process a partial or incomplete response because it has timed out or stopped waiting for the full response from the Docling backend.
@tjbck commented on GitHub (Apr 1, 2025):
@FabioPolito24
@convernaticspeter commented on GitHub (Apr 1, 2025):
This is an issue that happens with any longer PDF no matter how the content is extracted. I have the same issue with Standard method and also Document Intelligence from Azure.
Important: the more text the PDF has the longer the extraction is gonna take - and this is the issue here. PDFs with not a lot of text but still being big (24+ MB) won't have the same issue!
The issue seems to lie in the architecture of the uploading process. Instead of 2 different states "uploading" and "processing" there is only one state: "uploading". When the process of extracting the content of the PDF takes too long then some timeout cuts the connection and the upload fails without any error message.
If it isn't that then the content extraction has an issue with certain PDFs - but as the issue seems to depend on the amount of text I think that is unlikely.
This is how the console typically looks like in Firefox for this issue:
`Processing file:
Object { name: "GROHE_Bathroom_Brochure.pdf", type: "application/pdf", size: 17544599, extension: "pdf" }
MessageInput.svelte:221:11
Object { type: "file", file: "", id: null, url: "", name: "GROHE_Bathroom_Brochure2.pdf", collection_name: "", status: "uploading", size: 17544599, error: "", itemId: "4d649231-d980-432f-bee7-fb4ee7eeaa7f" }
FileItemModal.svelte:24:10
XHRPOST
https://chat.test.com/api/v1/files/
[HTTP/3 500 122990ms]
SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data index.ts:22:11`
This file, posted by another user in another thread, is a good test subject as it is large enough to trigger this behaviour on my setup (Plesk, LSWS, OpenWebUI in Docker): https://github.com/user-attachments/files/18858136/GROHE_Bathroom_Brochure.pdf
I already increased all timeout-limits beyond 30mins.
@FabioPolito24 commented on GitHub (Apr 2, 2025):
I was unable to reproduce the bug. I tried the configuration described but didn't encounter any errors. Any additional details about your environment, steps to reproduce, or error logs would be very helpful. I'll revisit this issue in the coming days when I have more time to investigate thoroughly and try different configurations.
@Infinnerty commented on GitHub (Apr 2, 2025):
Hey @FabioPolito24,
I spent some more time digging into my setup (we host Open-WebUI inside GKE/k8s), and it turns this is all related to load balancing/networking. Specifically, the default GKE Gateway timeout was too short (30 second default). This is not an Open WebUI problem and I used a GCPBackendPolicy to increase the backend service timeout for the Open WebUI service.
See the Google Cloud docs: https://cloud.google.com/kubernetes-engine/docs/how-to/configure-gateway-resources#configure_timeout
Hope this helps! Feel free to close.
Infinnerty
@BakirBukvic commented on GitHub (Aug 12, 2025):
I had the same bug. Here's the error log in docling: {'type': 'missing', 'loc': ('response', 'processing_time'), 'msg': 'Field required', 'input': HTTPException(status_code=504, detail='Conversion is taking too long. The maximum wait time is configure as DOCLING_SERVE_MAX_SYNC_WAIT=120.')}
Change the DOCLING_SERVE_MAX_SYNC_WAIT to something bigger, in seconds, when starting your instance.
@ManuXD32 commented on GitHub (Nov 24, 2025):
Hi! Where do you change that in the docker instance?
Thanks in advance
@BakirBukvic commented on GitHub (Nov 24, 2025):
This is an enviorment variable.
When setting up your docker instance, you need to declare DOCLING_SERVE_MAX_SYNC_WAIT=10000
@hdnh2006 commented on GitHub (Apr 15, 2026):
This doesn't work