mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 10:58:17 -05:00
[GH-ISSUE #17446] issue: file upload bug from 0.6.23 #56956
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 @K7cl on GitHub (Sep 14, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/17446
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.6.28
Ollama Version (if applicable)
No response
Operating System
Ubuntu 22.04.5 LTS
Browser (if applicable)
No response
Confirmation
README.md.Expected Behavior
file must be ready after /process/status return complete
Actual Behavior
after file uploaded and also receive complete from /process/status, ask immediately will get a return with No sources found and answer without any relevant to the uploaded file
Steps to Reproduce
docker main image, upload a pdf to chat and immediate press send after it available in webui. The response will no file enrolled
wait about half minute after available or re-generate after a few seconds will get a normal response with uploaded file as retrieved source
Logs & Screenshots
same problem with https://github.com/open-webui/open-webui/discussions/17021
Additional Information
No response
@eXt73 commented on GitHub (Sep 14, 2025):
You beat me to it, so I was about to report this too. It's a matter of embedding the document—whether in Chrome or Qdrant—the process has been taking quite a while lately...and even though it hasn't been completed, Open-WebUI claims it's already been done = 'document missing' error. There should be some better verification mechanism here to indicate whether the embedding has actually taken place.
@tjbck commented on GitHub (Sep 15, 2025):
This should be addressed in dev, testing wanted here!
@K7cl commented on GitHub (Sep 15, 2025):
great, I'll pull dev docker image and try now.
@K7cl commented on GitHub (Sep 15, 2025):
Fixed! Test done and work fine with docker dev tag image and is upgrade from previous bug version. Thanks for quick fix 👍
@sanchitbhavsar commented on GitHub (Sep 16, 2025):
I am having the same issue where the uploaded file data is processed and vector data is stored (pinecone) but the info about file is unknown to the model but appears later chats when its sees in context.
@tjbck @K7cl will the fix will be released in new version? or whats a alternative patch for now? Thanks
@K7cl commented on GitHub (Sep 16, 2025):
upgrade to dev version can fix this for now
@sanchitbhavsar commented on GitHub (Sep 16, 2025):
when is the plan to release the next version?
@rgaricano commented on GitHub (Sep 16, 2025):
To avoid this kind of issues when I upload files I always add in the prompt something like: (file is in context)
@sanchitbhavsar commented on GitHub (Sep 16, 2025):
yes but it also does not help because it complains no files seeing in the context.
I do not see any transaction data file uploaded yet—only the field mapping reference (uploaded in KB) is present in the context. Please upload an Excel or CSV file containing the transaction data you would like me to reconcile.@K7cl commented on GitHub (Sep 16, 2025):
I think you should ask the project maintainer, I have this question too
@rgaricano commented on GitHub (Sep 16, 2025):
OK, then is because now the uploads are async, and when the question is forwared to the model the file upload proccess isn't finished.There was some other issues reported about this (e.g. https://discord.com/channels/1170866489302188073/1412949935334101073 )
The async upload is fine for knowledge, collection or batches but for direct uploads in chat message could be an inconvenient.(right now, a workaround could be wait some seconds after upload the file and before send the question)
@sanchitbhavsar commented on GitHub (Sep 17, 2025):
@K7cl @rgaricano is this also relates to the changes introduced in v0.6.26
Configurable File Upload Processing Mode: Added "process_in_background" query parameter to the file upload API endpoint, allowing clients to choose between asynchronous (default) and synchronous file processing. Setting "process_in_background=false" forces the upload request to wait until extraction and embedding complete, returning immediately usable files and simplifying integration for backend API consumers that prefer blocking calls over polling workflows.@sanchitbhavsar commented on GitHub (Sep 17, 2025):
@tjbck why is this issue being closed? and when is the plan release for the fix? thanks
@ccoryellnf commented on GitHub (Sep 18, 2025):
I am experiencing this same issue. Have been since v.0.6.22. I deal with rather large documents, so it is a significant issue for my users.
@m20l22 commented on GitHub (Sep 19, 2025):
+1
@knorr3 commented on GitHub (Oct 6, 2025):
FYI, I don't know when exactly this was fixed, but it works in v0.6.32 now.
@m20m22 commented on GitHub (Oct 6, 2025):
hi, @tjbck
maybe you can link the relevant commit?
@brogan-wilding commented on GitHub (Mar 30, 2026):
I am checking the comments for issue 17446 to see if there was a fix for the stale replica read issue.