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

[GH-ISSUE #16889] feat: Add option to disable Asynchronous File Upload with Polling (allow synchronous/“process-now” mode) #18088

New Issue
Closed
opened 2026-04-20 00:02:03 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-20 00:02:03 -05:00
Owner
Copy Link

Originally created by @MrDick-11 on GitHub (Aug 25, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/16889

Check Existing Issues

  • I have searched the existing issues and discussions.

Problem Description

Since v0.6.23 Open WebUI introduced Asynchronous File Upload with Polling (see release notes) which changed file handling semantics: after POST /api/v1/files/ backend returns a record while extraction/embedding runs in background, so clients observe pending state until processing completes. This broke our existing integrations that relied on immediate (synchronous) availability of extracted content.

References:
– v0.6.23 release notes (async file upload w/ polling).
GitHub

– Design discussion for async + polling due to timeouts (Cloudflare 524) and maintainer link to the refactor.
GitHub

– Tracking issue for “make file upload process async (w/ polling)”.
GitHub

Desired Solution you'd like

Request: please add a configurable option to opt-out from async upload for server-side API callers, e.g.:

Env var: ASYNC_FILE_UPLOAD=false (global default), or

API flag on upload: POST /api/v1/files?processSync=true to block until extraction/embedding finishes, returning the final file object (as pre-0.6.23 behavior).

Why: some backend integrations (no browser/UI) are simpler and more reliable with a single blocking call (no polling/state machine). We’re OK with longer request times on our own infra (no Cloudflare/60s limit), and we handle larger timeouts.

Alternatives Considered

Acceptance criteria:

When sync mode is enabled, POST /api/v1/files returns only after extraction/embedding completes; returned JSON includes populated data/hash and the file is immediately usable in RAG/knowledge.

When async mode is enabled (default), behavior remains unchanged (202/200 + polling on the client side).

Clear docs for both modes and any server-side timeout knobs affecting sync behavior.

Notes: Today there is a process query param, but it only toggles whether to start processing, not whether the call waits for completion. A true “sync” path would eliminate extra polling code on the client.

Additional Context

No response

Originally created by @MrDick-11 on GitHub (Aug 25, 2025). Original GitHub issue: https://github.com/open-webui/open-webui/issues/16889 ### Check Existing Issues - [x] I have searched the existing issues and discussions. ### Problem Description Since v0.6.23 Open WebUI introduced Asynchronous File Upload with Polling (see release notes) which changed file handling semantics: after POST /api/v1/files/ backend returns a record while extraction/embedding runs in background, so clients observe pending state until processing completes. This broke our existing integrations that relied on immediate (synchronous) availability of extracted content. References: – v0.6.23 release notes (async file upload w/ polling). [GitHub](https://github.com/open-webui/open-webui/releases) – Design discussion for async + polling due to timeouts (Cloudflare 524) and maintainer link to the refactor. [GitHub](https://github.com/open-webui/open-webui/discussions/6648) – Tracking issue for “make file upload process async (w/ polling)”. [GitHub](https://github.com/open-webui/open-webui/issues/15023?utm_source=chatgpt.com) ### Desired Solution you'd like Request: please add a configurable option to opt-out from async upload for server-side API callers, e.g.: Env var: ASYNC_FILE_UPLOAD=false (global default), or API flag on upload: POST /api/v1/files?processSync=true to block until extraction/embedding finishes, returning the final file object (as pre-0.6.23 behavior). Why: some backend integrations (no browser/UI) are simpler and more reliable with a single blocking call (no polling/state machine). We’re OK with longer request times on our own infra (no Cloudflare/60s limit), and we handle larger timeouts. ### Alternatives Considered Acceptance criteria: When sync mode is enabled, POST /api/v1/files returns only after extraction/embedding completes; returned JSON includes populated data/hash and the file is immediately usable in RAG/knowledge. When async mode is enabled (default), behavior remains unchanged (202/200 + polling on the client side). Clear docs for both modes and any server-side timeout knobs affecting sync behavior. Notes: Today there is a process query param, but it only toggles whether to start processing, not whether the call waits for completion. A true “sync” path would eliminate extra polling code on the client. ### Additional Context _No response_
GiteaMirror commented 2026-04-20 00:02:08 -05:00
Author
Owner
Copy Link

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

Will take a look.

<!-- gh-comment-id:3219607210 --> @tjbck commented on GitHub (Aug 25, 2025): Will take a look.
GiteaMirror commented 2026-04-20 00:02:10 -05:00
Author
Owner
Copy Link

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

Addressed with c61698efcf

<!-- gh-comment-id:3220493834 --> @tjbck commented on GitHub (Aug 25, 2025): Addressed with c61698efcfc9617a2a605ba7cd9e85f41616f552
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
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#18088
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?