github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-06 19:08:59 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #12276] issue: Premature file upload termination (Docling); 504 & JSON errors #32058

New Issue
Closed
opened 2026-04-25 05:56:49 -05:00 by GiteaMirror · 8 comments
GiteaMirror commented 2026-04-25 05:56:49 -05:00
Owner
Copy Link

Originally created by @Infinnerty on GitHub (Apr 1, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/12276

Check Existing Issues

  • I have searched the existing issues and discussions.
  • I am using the latest version of Open WebUI.

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

  • 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 listed steps to reproduce the bug in detail.

Expected Behavior

The OpenWebUI should:

  • Maintain the visual representation of the uploaded file in the UI throughout the Docling processing duration.
  • Only remove the file entry (or update its status) after Docling has completed processing, either successfully or with an error.
  • Display a success or failure message after Docling completes its processing.
  • Handle backend errors gracefully and display appropriate error messages to the user.
  • Handle a long-running conversation process?

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

  1. Upload a reasonably large file (e.g., a PDF or TXT document) through the OpenWebUI interface.
  2. Immediately open the browser's developer console (usually by pressing F12).
  3. Monitor the network requests in the console.
  4. Observe the Docling logs to confirm that the file is received and processing has started.
  5. Notice that the uploaded file entry disappears from the OpenWebUI interface before Docling finishes processing.
  6. See the 504 error and JSON parsing error in the browser console.

Logs & Screenshots

Docling Logs:

docling-69b5d85fd5-kmhfc INFO:    2025-04-01 10:32:15,568 - docling_serve.app - Received 1 files for processing.                          
docling-69b5d85fd5-kmhfc INFO:    2025-04-01 10:32:15,569 - docling_serve.docling_conversion - artifacts_path is set to a valid directory.
docling-69b5d85fd5-kmhfc INFO:    2025-04-01 10:32:15,576 - docling.document_converter - Going to convert document batch...               
docling-69b5d85fd5-kmhfc INFO:    2025-04-01 10:32:15,577 - docling.utils.accelerator_utils - Accelerator device: 'cpu'                   
docling-69b5d85fd5-kmhfc INFO:    2025-04-01 10:32:17,718 - docling.utils.accelerator_utils - Accelerator device: 'cpu'                   
docling-69b5d85fd5-kmhfc INFO:    2025-04-01 10:32:18,864 - docling.utils.accelerator_utils - Accelerator device: 'cpu'                   
docling-69b5d85fd5-kmhfc INFO:     100.32.8.65:19611 - "GET /health HTTP/1.1" 200 OK                                                      
docling-69b5d85fd5-kmhfc INFO:     100.32.8.65:11630 - "GET /health HTTP/1.1" 200 OK                                                      
docling-69b5d85fd5-kmhfc INFO:     100.32.8.65:41168 - "GET /health HTTP/1.1" 200 OK                                                      
docling-69b5d85fd5-kmhfc INFO:    2025-04-01 10:32:20,081 - docling.pipeline.base_pipeline - Processing document d4ed7df1-4024-4734-8148-e
docling-69b5d85fd5-kmhfc INFO:     100.32.8.65:47491 - "GET /health HTTP/1.1" 200 OK                                                      
docling-69b5d85fd5-kmhfc INFO:     100.32.8.65:58245 - "GET /health HTTP/1.1" 200 OK                                                      
docling-69b5d85fd5-kmhfc INFO:     100.32.8.65:5543 - "GET /health HTTP/1.1" 200 OK                                                       
docling-69b5d85fd5-kmhfc INFO:    2025-04-01 10:32:53,826 - docling.document_converter - Finished converting document d4ed7df1-4024-4734-8
docling-69b5d85fd5-kmhfc INFO:    2025-04-01 10:32:53,828 - docling_serve.response_preparation - Processed 1 docs in 38.26 seconds.

Browser Console Logs:

Processing file:
Object { name: "JP Morgan LLY Eli Lilly & Company Notes From The Road - Takeaways fro.pdf", type: "application/pdf", size: 339984, extension: "pdf" }
MessageInput.svelte:221:11
XHRPOSThttps://ai.development.XXX.com/api/v1/files/[HTTP/2 504 30022ms]
Object { type: "file", file: "", id: null, url: "", name: "JP Morgan LLY Eli Lilly & Company Notes From The Road - Takeaways fro.pdf", collection_name: "", status: "uploading", size: 339984, error: "", itemId: "c9654b56-52a3-4a9b-af1a-36b018ce8307" }
FileItemModal.svelte:24:10
SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data

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.

Image

Originally created by @Infinnerty on GitHub (Apr 1, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/12276 ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### 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 - [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 listed steps to reproduce the bug in detail. ### Expected Behavior The OpenWebUI should: - Maintain the visual representation of the uploaded file in the UI throughout the Docling processing duration. - Only remove the file entry (or update its status) after Docling has completed processing, either successfully or with an error. - Display a success or failure message after Docling completes its processing. - Handle backend errors gracefully and display appropriate error messages to the user. - Handle a long-running conversation process? ### 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 1. Upload a reasonably large file (e.g., a PDF or TXT document) through the OpenWebUI interface. 2. Immediately open the browser's developer console (usually by pressing F12). 3. Monitor the network requests in the console. 4. Observe the Docling logs to confirm that the file is received and processing has started. 5. Notice that the uploaded file entry disappears from the OpenWebUI interface before Docling finishes processing. 6. See the 504 error and JSON parsing error in the browser console. ### Logs & Screenshots Docling Logs: ``` docling-69b5d85fd5-kmhfc INFO: 2025-04-01 10:32:15,568 - docling_serve.app - Received 1 files for processing. docling-69b5d85fd5-kmhfc INFO: 2025-04-01 10:32:15,569 - docling_serve.docling_conversion - artifacts_path is set to a valid directory. docling-69b5d85fd5-kmhfc INFO: 2025-04-01 10:32:15,576 - docling.document_converter - Going to convert document batch... docling-69b5d85fd5-kmhfc INFO: 2025-04-01 10:32:15,577 - docling.utils.accelerator_utils - Accelerator device: 'cpu' docling-69b5d85fd5-kmhfc INFO: 2025-04-01 10:32:17,718 - docling.utils.accelerator_utils - Accelerator device: 'cpu' docling-69b5d85fd5-kmhfc INFO: 2025-04-01 10:32:18,864 - docling.utils.accelerator_utils - Accelerator device: 'cpu' docling-69b5d85fd5-kmhfc INFO: 100.32.8.65:19611 - "GET /health HTTP/1.1" 200 OK docling-69b5d85fd5-kmhfc INFO: 100.32.8.65:11630 - "GET /health HTTP/1.1" 200 OK docling-69b5d85fd5-kmhfc INFO: 100.32.8.65:41168 - "GET /health HTTP/1.1" 200 OK docling-69b5d85fd5-kmhfc INFO: 2025-04-01 10:32:20,081 - docling.pipeline.base_pipeline - Processing document d4ed7df1-4024-4734-8148-e docling-69b5d85fd5-kmhfc INFO: 100.32.8.65:47491 - "GET /health HTTP/1.1" 200 OK docling-69b5d85fd5-kmhfc INFO: 100.32.8.65:58245 - "GET /health HTTP/1.1" 200 OK docling-69b5d85fd5-kmhfc INFO: 100.32.8.65:5543 - "GET /health HTTP/1.1" 200 OK docling-69b5d85fd5-kmhfc INFO: 2025-04-01 10:32:53,826 - docling.document_converter - Finished converting document d4ed7df1-4024-4734-8 docling-69b5d85fd5-kmhfc INFO: 2025-04-01 10:32:53,828 - docling_serve.response_preparation - Processed 1 docs in 38.26 seconds. ``` Browser Console Logs: ``` Processing file: Object { name: "JP Morgan LLY Eli Lilly & Company Notes From The Road - Takeaways fro.pdf", type: "application/pdf", size: 339984, extension: "pdf" } MessageInput.svelte:221:11 XHRPOSThttps://ai.development.XXX.com/api/v1/files/[HTTP/2 504 30022ms] Object { type: "file", file: "", id: null, url: "", name: "JP Morgan LLY Eli Lilly & Company Notes From The Road - Takeaways fro.pdf", collection_name: "", status: "uploading", size: 339984, error: "", itemId: "c9654b56-52a3-4a9b-af1a-36b018ce8307" } FileItemModal.svelte:24:10 SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data ``` ### 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. ![Image](https://github.com/user-attachments/assets/3d23380a-7cec-4436-98a4-cbfa78be0d7b)
GiteaMirror added the bug label 2026-04-25 05:56:49 -05:00
GiteaMirror commented 2026-04-25 05:56:50 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Apr 1, 2025):

@FabioPolito24

<!-- gh-comment-id:2769084409 --> @tjbck commented on GitHub (Apr 1, 2025): @FabioPolito24
GiteaMirror commented 2026-04-25 05:56:50 -05:00
Author
Owner
Copy Link

@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.

<!-- gh-comment-id:2770743975 --> @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](https://chat.test.com/src/lib/components/chat/MessageInput.svelte) 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](https://chat.test.com/src/lib/components/common/FileItemModal.svelte) 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](https://chat.test.com/src/lib/apis/files/index.ts)` 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.
GiteaMirror commented 2026-04-25 05:56:51 -05:00
Author
Owner
Copy Link

@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.

<!-- gh-comment-id:2770938769 --> @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.
GiteaMirror commented 2026-04-25 05:56:51 -05:00
Author
Owner
Copy Link

@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

<!-- gh-comment-id:2772079331 --> @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
GiteaMirror commented 2026-04-25 05:56:52 -05:00
Author
Owner
Copy Link

@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.

<!-- gh-comment-id:3178219708 --> @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.
GiteaMirror commented 2026-04-25 05:56:53 -05:00
Author
Owner
Copy Link

@ManuXD32 commented on GitHub (Nov 24, 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.

Hi! Where do you change that in the docker instance?
Thanks in advance

<!-- gh-comment-id:3572997861 --> @ManuXD32 commented on GitHub (Nov 24, 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. Hi! Where do you change that in the docker instance? Thanks in advance
GiteaMirror commented 2026-04-25 05:56:53 -05:00
Author
Owner
Copy Link

@BakirBukvic commented on GitHub (Nov 24, 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.

Hi! Where do you change that in the docker instance?
Thanks in advance

This is an enviorment variable.
When setting up your docker instance, you need to declare DOCLING_SERVE_MAX_SYNC_WAIT=10000

<!-- gh-comment-id:3573027098 --> @BakirBukvic commented on GitHub (Nov 24, 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. > > Hi! Where do you change that in the docker instance? > Thanks in advance This is an enviorment variable. When setting up your docker instance, you need to declare DOCLING_SERVE_MAX_SYNC_WAIT=10000
GiteaMirror commented 2026-04-25 05:56:54 -05:00
Author
Owner
Copy Link

@hdnh2006 commented on GitHub (Apr 15, 2026):

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.

This doesn't work

<!-- gh-comment-id:4252719260 --> @hdnh2006 commented on GitHub (Apr 15, 2026): > 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. This doesn't work
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#32058
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?