github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-15 21:19:39 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

[GH-ISSUE #24807] issue: Knowledge upload can leave processed files unlinked if the user navigates away before final linking #123716

New Issue
Closed
opened 2026-05-21 03:10:50 -05:00 by GiteaMirror · 6 comments
GiteaMirror commented 2026-05-21 03:10:50 -05:00
Owner
Copy Link

Originally created by @hytg on GitHub (May 16, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/24807

Check Existing Issues

  • 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.5

Ollama Version (if applicable)

not used

Operating System

macOS Tahoe 26.5（25F71）

Browser (if applicable)

Chromium via Playwright-automated reproduction
Also reproducible manually in Chrome-based browsers

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of Open WebUI.
  • 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.

Summary

This issue describes two related navigation-timing modes:

  • Mode A — primary correctness bug: navigation occurs before /file/add is sent. The file is processed successfully, but it is never linked to the Knowledge Collection. This creates a persistent inconsistent state with no recovery.
  • Mode B — related UX / state-visibility bug: navigation occurs after /file/add is sent, but before it completes. The backend eventually links the file, but the UI temporarily shows an empty Knowledge Collection and provides no indication that linking is still running.

Both modes appear to come from the same fragile flow: the final Knowledge linking step depends on frontend code that runs only after file processing completes and the original page is still mounted.

Timing model

upload 200
  |
  |------ Mode A window ------|
  |                           |
SSE opened              frontend sends /file/add
                              |
                              |------ Mode B window ------|
                              |                           |
                         /file/add in-flight       backend completes linking
                                                          |
                                                          |--- visible after manual reload

Mode A:

navigation occurs before the frontend sends /file/add
→ backend never receives the linking request
→ Knowledge Collection remains empty permanently

Mode B:

navigation occurs after frontend sends /file/add
but before /file/add returns 200
→ backend continues processing
→ Knowledge Collection is linked eventually
→ UI shows empty collection while work is running
→ UI does not automatically update when work completes

Expected Behavior

When a file is uploaded to a Knowledge Collection, it should be reliably linked to that Knowledge Collection after backend processing completes.

This should remain true even if the user:

  • navigates away from the Knowledge Collection page
  • reloads the page
  • closes the browser tab during processing

At minimum, Open WebUI should not enter a state where:

  • Global Files contains the uploaded file
  • the file status is completed
  • the Knowledge Collection file list is empty
  • the UI gives no indication whether Knowledge linking failed, is still running, or can be recovered

The correctness of the file → Knowledge Collection linking step should not depend on the original browser page remaining mounted until all processing and linking work has finished.

A durable behavior would be:

upload to Knowledge Collection
→ backend processes file
→ backend completes or recovers the Knowledge Collection association
→ Knowledge Collection eventually shows the uploaded file

The user should not need to keep the original upload page open for the final Knowledge Collection association to succeed.

Actual Behavior

Uploading a file to a Knowledge Collection currently appears to depend on a frontend-driven final linking step.

Observed flow:

1. Frontend uploads file
   POST /api/v1/files/

2. Frontend opens SSE status stream
   GET /api/v1/files/{file_id}/process/status?stream=true

3. Backend processes the file

4. SSE emits completed

5. Frontend sends final linking request
   POST /api/v1/knowledge/{knowledge_id}/file/add

6. /file/add performs Knowledge Collection vector DB work and inserts the knowledge_file association

7. /file/add returns 200

8. The file becomes visible in the Knowledge Collection after refresh / reload

This creates two navigation-sensitive modes.

Mode A — primary correctness bug

Mode A occurs when the user navigates away before the frontend sends:

POST /api/v1/knowledge/{knowledge_id}/file/add

In this mode:

  • the upload succeeds
  • backend file-level processing continues after navigation
  • embeddings are generated successfully
  • the file appears in Global Files with status completed
  • no /file/add request is ever sent
  • the Knowledge Collection remains empty indefinitely
  • no automatic recovery or relinking occurs

Observed final state:

Global Files contains uploaded file:         yes
Global file status:                          completed
Knowledge file list contains uploaded file:  no
Automatic recovery observed:                 no

This is the primary correctness issue: a successfully processed file can be permanently left unlinked from the Knowledge Collection it was uploaded into.

Mode B — related UX / state-visibility bug

Mode B occurs when the user navigates away after /file/add has been sent, but before it returns 200.

In this mode, the backend eventually links the file to the Knowledge Collection. However, the UI state is misleading while that backend work is still running.

Observed behavior:

  • the browser reports ERR_ABORTED
  • the backend continues processing /file/add
  • the Knowledge Collection appears empty while backend linking is still running
  • there is no in-progress indicator
  • there is no notification that Knowledge linking is still running
  • the page does not automatically update when linking completes
  • the file only becomes visible after the backend finishes and the user manually reloads

Observed final state:

Global Files contains uploaded file:         yes
Global file status:                          completed
Knowledge file list during backend work:     empty
Knowledge file list after backend finishes:  linked, visible after manual reload
Automatic UI update observed:                no

Mode B is not the same as Mode A: the backend eventually succeeds. But it exposes the same underlying fragility and leaves the user looking at an empty Knowledge Collection with no actionable status.

Steps to Reproduce

Environment used:

  • Host OS: macOS
  • Container runtime: Colima / Docker
  • Open WebUI image: ghcr.io/open-webui/open-webui:dev
  • Open WebUI version: v0.9.5
  • Commit: 359590ca9d06ee89f616b8a3caebdade93f6228b
  • Image digest: sha256:4cfb1bc021aa25e2831625b38c4a91aa0c2da5720e52c247555d1116e946482e
  • Image created: 2026-05-15T00:35:19Z
  • Ollama: not used
  • Embedding provider: Open WebUI built-in (sentence-transformers/all-MiniLM-L6-v2, default)

Steps:

  1. Start Open WebUI using Docker.

  2. Log in as an admin user.

  3. Go to:

    /workspace/knowledge

  4. Create a new Knowledge Collection.

  5. Open the Knowledge Collection detail page.

  6. Upload a PDF file that keeps backend processing running long enough for navigation to happen before linking completes.

    The root trigger is navigation timing.

    File byte size, extracted text density, chunk count, and embedding latency only affect the length of the vulnerable windows. They make the issue easier or harder to reproduce, but they are not the underlying cause.

  7. To reproduce Mode A, navigate away to:

    /workspace/knowledge

    while the upload spinner is still shown and before the SSE status stream completes.

  8. To reproduce Mode B, navigate away shortly after the spinner disappears, after /file/add has been sent, but before:

    POST /api/v1/knowledge/{knowledge_id}/file/add

    receives a 200 response.

  9. Navigate back to the same Knowledge Collection page.

  10. Observe the result.

Expected:

  • The uploaded file appears in the Knowledge Collection file list, or the UI clearly shows that Knowledge linking is still in progress.

Actual:

  • In Mode A, the file remains in Global Files with status completed, but the Knowledge Collection remains empty indefinitely.
  • In Mode B, the Knowledge Collection initially appears empty while backend linking is still running. The file appears only after backend processing finishes and the user manually reloads the page.

Logs & Screenshots

Exact API sequence observed for Mode A

03:17:49  POST /api/v1/files/                                          → 200
03:17:50  GET  /api/v1/files/{file_id}/process/status?stream=true      → 200, SSE opened
03:17:50  [backend] generating embeddings for file-{file_id}

03:18:20  [user navigates away to /workspace/knowledge]
          GET /api/v1/files/{file_id}/process/status?stream=true       → ERR_ABORTED

03:18:56  [backend] embeddings generated: 1540 items
03:18:57  [backend] added 1540 items to collection file-{file_id}
03:18:57  [backend] process_file: added 220 items to collection file-{file_id}

          Backend file processing completed successfully, but no /file/add request was ever sent.

03:19:02  [user navigates back to Knowledge Collection page]
          GET /api/v1/knowledge/{knowledge_id}/files?page=1            → [] empty
          POST /api/v1/knowledge/{knowledge_id}/file/add               → never sent

Navigation occurred approximately 30 seconds after upload started.

Backend processing completed approximately 37 seconds after navigation, for a total of approximately 67 seconds from upload start.

The log contains both 1540 items and 220 items messages. These appear to refer to different internal units, likely split vector items versus pre-split documents/pages. The important point is that backend file-level processing completed successfully and populated file-{file_id}.

Backend log highlights for Mode A

03:17:49  INFO  open_webui.routers.files:upload_file_handler - file.content_type: application/pdf True
03:17:49  INFO  "POST /api/v1/files/ HTTP/1.1" 200
03:17:50  INFO  "GET /api/v1/files/{file_id}/process/status?stream=true HTTP/1.1" 200
03:17:50  INFO  open_webui.routers.retrieval:save_docs_to_vector_db - generating embeddings for file-{file_id}

03:18:20  INFO  "GET /workspace/knowledge HTTP/1.1" 200

03:18:56  INFO  open_webui.routers.retrieval:save_docs_to_vector_db - embeddings generated 1540 for 1540 items
03:18:57  INFO  open_webui.routers.retrieval:save_docs_to_vector_db - adding to collection file-{file_id}
03:18:57  INFO  open_webui.routers.retrieval:save_docs_to_vector_db - added 1540 items to collection file-{file_id}
03:18:57  INFO  open_webui.routers.retrieval:process_file - added 220 items to collection file-{file_id}

03:19:02  INFO  "GET /api/v1/knowledge/{knowledge_id}/files?page=1&directory_id= HTTP/1.1" 200

No /api/v1/knowledge/{knowledge_id}/file/add request appears anywhere in the backend log for this Mode A reproduction.

Important clarification

In these logs, collection file-{file_id} refers to the file-level vector collection, not the user-created Knowledge Collection.

The file itself is processed successfully. The failed part is the final file → Knowledge Collection linking step.

Mode B observation

In another reproduction, /file/add was sent after file-level processing completed, but the user navigated away while the request was still in-flight.

The browser reported ERR_ABORTED. However, backend logs confirm that the backend continued processing /file/add after the client disconnected and eventually completed the Knowledge Collection embedding.

07:30:39  process_file complete, file-level processing finished
07:30:40  POST /api/v1/knowledge/{knowledge_id}/file/add → sent by frontend
07:30:40  [user navigates away]
          Browser reports ERR_ABORTED
07:30:40  save_docs_to_vector_db: generating embeddings for {knowledge_id}
07:30:41  GET /api/v1/knowledge/{knowledge_id}/files?page=1 → [] empty while backend is still running
          [~67 seconds of Knowledge Collection embedding work]
07:31:49  added 1540 items to collection {knowledge_id}

The Knowledge Collection appears empty when the user first returns to the page, because the backend embedding work is still in progress.

Once the backend finishes, the file link is present. However, the UI does not update automatically. A manual reload is required to see the file.

Additional Information

Observed file size threshold for UI reproduction

In the test environment described above (Open WebUI v0.9.5), both Mode A and Mode B were reproduced via browser UI automation.

A 54-page text-dense synthetic PDF (~55 KB) was the smallest profile that reliably reproduced both modes. A 40-page PDF (~40 KB) frequently completed processing before the navigation window opened and could not reliably reproduce either mode.

File-level processing for the 54-page file took approximately 67 seconds end-to-end. Knowledge collection embedding (/file/add) also took approximately 67 seconds. These durations depend on text density, chunk count, and embedding provider latency, and will vary across deployments.

Originally created by @hytg on GitHub (May 16, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/24807 ### 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.5 ### Ollama Version (if applicable) not used ### Operating System macOS Tahoe 26.5（25F71） ### Browser (if applicable) Chromium via Playwright-automated reproduction Also reproducible manually in Chrome-based browsers ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of Open WebUI. - [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. ### Summary This issue describes two related navigation-timing modes: * **Mode A — primary correctness bug:** navigation occurs before `/file/add` is sent. The file is processed successfully, but it is never linked to the Knowledge Collection. This creates a persistent inconsistent state with no recovery. * **Mode B — related UX / state-visibility bug:** navigation occurs after `/file/add` is sent, but before it completes. The backend eventually links the file, but the UI temporarily shows an empty Knowledge Collection and provides no indication that linking is still running. Both modes appear to come from the same fragile flow: the final Knowledge linking step depends on frontend code that runs only after file processing completes and the original page is still mounted. ### Timing model ```text upload 200 | |------ Mode A window ------| | | SSE opened frontend sends /file/add | |------ Mode B window ------| | | /file/add in-flight backend completes linking | |--- visible after manual reload ``` Mode A: ```text navigation occurs before the frontend sends /file/add → backend never receives the linking request → Knowledge Collection remains empty permanently ``` Mode B: ```text navigation occurs after frontend sends /file/add but before /file/add returns 200 → backend continues processing → Knowledge Collection is linked eventually → UI shows empty collection while work is running → UI does not automatically update when work completes ``` ### Expected Behavior When a file is uploaded to a Knowledge Collection, it should be reliably linked to that Knowledge Collection after backend processing completes. This should remain true even if the user: * navigates away from the Knowledge Collection page * reloads the page * closes the browser tab during processing At minimum, Open WebUI should not enter a state where: * Global Files contains the uploaded file * the file status is `completed` * the Knowledge Collection file list is empty * the UI gives no indication whether Knowledge linking failed, is still running, or can be recovered The correctness of the file → Knowledge Collection linking step should not depend on the original browser page remaining mounted until all processing and linking work has finished. A durable behavior would be: ```text upload to Knowledge Collection → backend processes file → backend completes or recovers the Knowledge Collection association → Knowledge Collection eventually shows the uploaded file ``` The user should not need to keep the original upload page open for the final Knowledge Collection association to succeed. ### Actual Behavior Uploading a file to a Knowledge Collection currently appears to depend on a frontend-driven final linking step. Observed flow: ```text 1. Frontend uploads file POST /api/v1/files/ 2. Frontend opens SSE status stream GET /api/v1/files/{file_id}/process/status?stream=true 3. Backend processes the file 4. SSE emits completed 5. Frontend sends final linking request POST /api/v1/knowledge/{knowledge_id}/file/add 6. /file/add performs Knowledge Collection vector DB work and inserts the knowledge_file association 7. /file/add returns 200 8. The file becomes visible in the Knowledge Collection after refresh / reload ``` This creates two navigation-sensitive modes. #### Mode A — primary correctness bug Mode A occurs when the user navigates away before the frontend sends: ```text POST /api/v1/knowledge/{knowledge_id}/file/add ``` In this mode: * the upload succeeds * backend file-level processing continues after navigation * embeddings are generated successfully * the file appears in Global Files with status `completed` * no `/file/add` request is ever sent * the Knowledge Collection remains empty indefinitely * no automatic recovery or relinking occurs Observed final state: ```text Global Files contains uploaded file: yes Global file status: completed Knowledge file list contains uploaded file: no Automatic recovery observed: no ``` This is the primary correctness issue: a successfully processed file can be permanently left unlinked from the Knowledge Collection it was uploaded into. #### Mode B — related UX / state-visibility bug Mode B occurs when the user navigates away after `/file/add` has been sent, but before it returns `200`. In this mode, the backend eventually links the file to the Knowledge Collection. However, the UI state is misleading while that backend work is still running. Observed behavior: * the browser reports `ERR_ABORTED` * the backend continues processing `/file/add` * the Knowledge Collection appears empty while backend linking is still running * there is no in-progress indicator * there is no notification that Knowledge linking is still running * the page does not automatically update when linking completes * the file only becomes visible after the backend finishes and the user manually reloads Observed final state: ```text Global Files contains uploaded file: yes Global file status: completed Knowledge file list during backend work: empty Knowledge file list after backend finishes: linked, visible after manual reload Automatic UI update observed: no ``` Mode B is not the same as Mode A: the backend eventually succeeds. But it exposes the same underlying fragility and leaves the user looking at an empty Knowledge Collection with no actionable status. ### Steps to Reproduce Environment used: * Host OS: macOS * Container runtime: Colima / Docker * Open WebUI image: `ghcr.io/open-webui/open-webui:dev` * Open WebUI version: `v0.9.5` * Commit: `359590ca9d06ee89f616b8a3caebdade93f6228b` * Image digest: `sha256:4cfb1bc021aa25e2831625b38c4a91aa0c2da5720e52c247555d1116e946482e` * Image created: `2026-05-15T00:35:19Z` * Ollama: not used * Embedding provider: Open WebUI built-in (sentence-transformers/all-MiniLM-L6-v2, default) Steps: 1. Start Open WebUI using Docker. 2. Log in as an admin user. 3. Go to: ```text /workspace/knowledge ``` 4. Create a new Knowledge Collection. 5. Open the Knowledge Collection detail page. 6. Upload a PDF file that keeps backend processing running long enough for navigation to happen before linking completes. The root trigger is navigation timing. File byte size, extracted text density, chunk count, and embedding latency only affect the length of the vulnerable windows. They make the issue easier or harder to reproduce, but they are not the underlying cause. 7. To reproduce **Mode A**, navigate away to: ```text /workspace/knowledge ``` while the upload spinner is still shown and before the SSE status stream completes. 8. To reproduce **Mode B**, navigate away shortly after the spinner disappears, after `/file/add` has been sent, but before: ```text POST /api/v1/knowledge/{knowledge_id}/file/add ``` receives a `200` response. 9. Navigate back to the same Knowledge Collection page. 10. Observe the result. Expected: * The uploaded file appears in the Knowledge Collection file list, or the UI clearly shows that Knowledge linking is still in progress. Actual: * In Mode A, the file remains in Global Files with status `completed`, but the Knowledge Collection remains empty indefinitely. * In Mode B, the Knowledge Collection initially appears empty while backend linking is still running. The file appears only after backend processing finishes and the user manually reloads the page. ### Logs & Screenshots #### Exact API sequence observed for Mode A ```text 03:17:49 POST /api/v1/files/ → 200 03:17:50 GET /api/v1/files/{file_id}/process/status?stream=true → 200, SSE opened 03:17:50 [backend] generating embeddings for file-{file_id} 03:18:20 [user navigates away to /workspace/knowledge] GET /api/v1/files/{file_id}/process/status?stream=true → ERR_ABORTED 03:18:56 [backend] embeddings generated: 1540 items 03:18:57 [backend] added 1540 items to collection file-{file_id} 03:18:57 [backend] process_file: added 220 items to collection file-{file_id} Backend file processing completed successfully, but no /file/add request was ever sent. 03:19:02 [user navigates back to Knowledge Collection page] GET /api/v1/knowledge/{knowledge_id}/files?page=1 → [] empty POST /api/v1/knowledge/{knowledge_id}/file/add → never sent ``` Navigation occurred approximately 30 seconds after upload started. Backend processing completed approximately 37 seconds after navigation, for a total of approximately 67 seconds from upload start. The log contains both `1540 items` and `220 items` messages. These appear to refer to different internal units, likely split vector items versus pre-split documents/pages. The important point is that backend file-level processing completed successfully and populated `file-{file_id}`. #### Backend log highlights for Mode A ```text 03:17:49 INFO open_webui.routers.files:upload_file_handler - file.content_type: application/pdf True 03:17:49 INFO "POST /api/v1/files/ HTTP/1.1" 200 03:17:50 INFO "GET /api/v1/files/{file_id}/process/status?stream=true HTTP/1.1" 200 03:17:50 INFO open_webui.routers.retrieval:save_docs_to_vector_db - generating embeddings for file-{file_id} 03:18:20 INFO "GET /workspace/knowledge HTTP/1.1" 200 03:18:56 INFO open_webui.routers.retrieval:save_docs_to_vector_db - embeddings generated 1540 for 1540 items 03:18:57 INFO open_webui.routers.retrieval:save_docs_to_vector_db - adding to collection file-{file_id} 03:18:57 INFO open_webui.routers.retrieval:save_docs_to_vector_db - added 1540 items to collection file-{file_id} 03:18:57 INFO open_webui.routers.retrieval:process_file - added 220 items to collection file-{file_id} 03:19:02 INFO "GET /api/v1/knowledge/{knowledge_id}/files?page=1&directory_id= HTTP/1.1" 200 ``` No `/api/v1/knowledge/{knowledge_id}/file/add` request appears anywhere in the backend log for this Mode A reproduction. #### Important clarification In these logs, `collection file-{file_id}` refers to the file-level vector collection, not the user-created Knowledge Collection. The file itself is processed successfully. The failed part is the final file → Knowledge Collection linking step. #### Mode B observation In another reproduction, `/file/add` was sent after file-level processing completed, but the user navigated away while the request was still in-flight. The browser reported `ERR_ABORTED`. However, backend logs confirm that the backend continued processing `/file/add` after the client disconnected and eventually completed the Knowledge Collection embedding. ```text 07:30:39 process_file complete, file-level processing finished 07:30:40 POST /api/v1/knowledge/{knowledge_id}/file/add → sent by frontend 07:30:40 [user navigates away] Browser reports ERR_ABORTED 07:30:40 save_docs_to_vector_db: generating embeddings for {knowledge_id} 07:30:41 GET /api/v1/knowledge/{knowledge_id}/files?page=1 → [] empty while backend is still running [~67 seconds of Knowledge Collection embedding work] 07:31:49 added 1540 items to collection {knowledge_id} ``` The Knowledge Collection appears empty when the user first returns to the page, because the backend embedding work is still in progress. Once the backend finishes, the file link is present. However, the UI does not update automatically. A manual reload is required to see the file. ### Additional Information #### Observed file size threshold for UI reproduction In the test environment described above (Open WebUI v0.9.5), both Mode A and Mode B were reproduced via browser UI automation. A 54-page text-dense synthetic PDF (~55 KB) was the smallest profile that reliably reproduced both modes. A 40-page PDF (~40 KB) frequently completed processing before the navigation window opened and could not reliably reproduce either mode. File-level processing for the 54-page file took approximately 67 seconds end-to-end. Knowledge collection embedding (`/file/add`) also took approximately 67 seconds. These durations depend on text density, chunk count, and embedding provider latency, and will vary across deployments.
GiteaMirror added the bug label 2026-05-21 03:10:50 -05:00
GiteaMirror commented 2026-05-21 03:10:53 -05:00
Author
Owner
Copy Link

@owui-terminator[bot] commented on GitHub (May 16, 2026):

🔍 Related Issues Found

I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions:

  1. 🟣 #22573 issue: Files Not Linked to Knowledge Collection When Dropped Simultaneously (FILE_NOT_PROCESSED Race Condition)
    This is the closest match: it describes files being uploaded and processed but never linked to the Knowledge Collection, leaving them effectively invisible. The trigger differs (simultaneous drag-drop vs navigation away), but both issues center on the fragile frontend-driven linking step after file processing.
    by jannefleischer · bug

  2. 🟢 #19190 issue: Synchronization with Folder Leads to Empty Knowledge Base
    This issue reports the UI showing an empty knowledge base after synchronization is interrupted, while the backend state may still contain files. It is related to the same class of stale/empty Knowledge Collection state versus backend reality, though the cause is folder sync rather than upload navigation timing.
    by flefevre · bug, confirmed issue

  3. 🟣 #20730 issue: API to knowledge doesn't list files
    This issue shows that the knowledge API can return files: null / not list files even when the knowledge object exists, which aligns with the symptom of a Knowledge Collection appearing empty despite backend-side data. It is a weaker but relevant state-visibility/listing issue.
    by sigi77 · bug

  4. 🟢 #10679 Batch add file to knowledge doesn't check for existence
    This bug is about the /knowledge/{id}/files/batch/add path and how knowledge-file addition behaves inconsistently. It is relevant because the new report also implicates the file-add/linking step as a separate backend operation after upload and processing.
    by almajo · bug, confirmed issue

💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead.

This comment was generated automatically. React with 👍 if helpful, 👎 if not.

<!-- gh-comment-id:4466448007 --> @owui-terminator[bot] commented on GitHub (May 16, 2026): <!-- terminator-bot:related-issues-reply --> 🔍 **Related Issues Found** I found some existing issues that might be related. Please check if any of these are duplicates or contain helpful solutions: 1. 🟣 [#22573](https://github.com/open-webui/open-webui/issues/22573) **issue: Files Not Linked to Knowledge Collection When Dropped Simultaneously (`FILE_NOT_PROCESSED` Race Condition)** *This is the closest match: it describes files being uploaded and processed but never linked to the Knowledge Collection, leaving them effectively invisible. The trigger differs (simultaneous drag-drop vs navigation away), but both issues center on the fragile frontend-driven linking step after file processing.* *by jannefleischer · `bug`* 2. 🟢 [#19190](https://github.com/open-webui/open-webui/issues/19190) **issue: Synchronization with Folder Leads to Empty Knowledge Base** *This issue reports the UI showing an empty knowledge base after synchronization is interrupted, while the backend state may still contain files. It is related to the same class of stale/empty Knowledge Collection state versus backend reality, though the cause is folder sync rather than upload navigation timing.* *by flefevre · `bug`, `confirmed issue`* 3. 🟣 [#20730](https://github.com/open-webui/open-webui/issues/20730) **issue: API to knowledge doesn't list files** *This issue shows that the knowledge API can return `files: null` / not list files even when the knowledge object exists, which aligns with the symptom of a Knowledge Collection appearing empty despite backend-side data. It is a weaker but relevant state-visibility/listing issue.* *by sigi77 · `bug`* 4. 🟢 [#10679](https://github.com/open-webui/open-webui/issues/10679) **Batch add file to knowledge doesn't check for existence** *This bug is about the `/knowledge/{id}/files/batch/add` path and how knowledge-file addition behaves inconsistently. It is relevant because the new report also implicates the file-add/linking step as a separate backend operation after upload and processing.* *by almajo · `bug`, `confirmed issue`* --- 💡 If your issue is a duplicate, please close it and add any additional details to the existing issue instead. *This comment was generated automatically.* React with 👍 if helpful, 👎 if not.
GiteaMirror commented 2026-05-21 03:10:54 -05:00
Author
Owner
Copy Link

@hytg commented on GitHub (May 16, 2026):

I think #22573 is the closest related case. Both issues have a similar end result: the file is completed in Global Files, but is not linked to the Knowledge Collection. However, the failure mode is different.

  • #22573: the frontend sends POST /knowledge/{id}/file/add before processing has completed → the backend returns 400 FILE_NOT_PROCESSED → the frontend does not recover from that error → the link request remains rejected and the file becomes orphaned.
  • This issue, Mode A: the frontend never sends /file/add at all. The user navigates away before the SSE stream completes, so backend file-level processing completes successfully, but the final Knowledge Collection link is never created.
  • This issue, Mode B: /file/add is sent and the backend eventually succeeds. However, from the browser side the request appears interrupted, the UI does not show that linking is still in progress, and the collection view does not refresh automatically after linking completes.

So the trigger and code path are different.

Also, #22573 is already closed, but the author mentioned in the closing comment that closing the browser window early can still lead to unlinked results. That sounds very close to the navigation / page-unmount case described here, but it was not the main subject of #22573 and appears to remain unresolved.

#19190 has a similar symptom in that the UI can show an empty Knowledge Collection while files still exist on the backend, but its trigger is interrupted folder synchronization, not navigation during upload.

#20730, where the Knowledge API returns files: null, and #10679, about missing duplicate checks in batch add, are both Knowledge/file-related issues, but they seem separate from this navigation-timing / frontend-driven final-linking problem.

Based on that, I think this issue is strongly related to #22573, but not an exact duplicate. In particular, the failure mode where the final file-to-Knowledge linking step depends on the original upload page staying mounted seems worth tracking separately.

<!-- gh-comment-id:4466509789 --> @hytg commented on GitHub (May 16, 2026): I think #22573 is the closest related case. Both issues have a similar end result: the file is `completed` in Global Files, but is not linked to the Knowledge Collection. However, the failure mode is different. - #22573: the frontend sends `POST /knowledge/{id}/file/add` before processing has completed → the backend returns `400 FILE_NOT_PROCESSED` → the frontend does not recover from that error → the link request remains rejected and the file becomes orphaned. - This issue, Mode A: the frontend never sends `/file/add` at all. The user navigates away before the SSE stream completes, so backend file-level processing completes successfully, but the final Knowledge Collection link is never created. - This issue, Mode B: `/file/add` is sent and the backend eventually succeeds. However, from the browser side the request appears interrupted, the UI does not show that linking is still in progress, and the collection view does not refresh automatically after linking completes. So the trigger and code path are different. Also, #22573 is already closed, but the author mentioned in the closing comment that closing the browser window early can still lead to unlinked results. That sounds very close to the navigation / page-unmount case described here, but it was not the main subject of #22573 and appears to remain unresolved. #19190 has a similar symptom in that the UI can show an empty Knowledge Collection while files still exist on the backend, but its trigger is interrupted folder synchronization, not navigation during upload. #20730, where the Knowledge API returns `files: null`, and #10679, about missing duplicate checks in batch add, are both Knowledge/file-related issues, but they seem separate from this navigation-timing / frontend-driven final-linking problem. Based on that, I think this issue is strongly related to #22573, but not an exact duplicate. In particular, the failure mode where the final file-to-Knowledge linking step depends on the original upload page staying mounted seems worth tracking separately.
GiteaMirror commented 2026-05-21 03:10:55 -05:00
Author
Owner
Copy Link

@hytg commented on GitHub (May 18, 2026):

I opened a design discussion for a possible fix direction here: https://github.com/open-webui/open-webui/discussions/24871

<!-- gh-comment-id:4478734735 --> @hytg commented on GitHub (May 18, 2026): I opened a design discussion for a possible fix direction here: https://github.com/open-webui/open-webui/discussions/24871
GiteaMirror commented 2026-05-21 03:10:56 -05:00
Author
Owner
Copy Link

@paulxg12 commented on GitHub (May 18, 2026):

I'd like to work on this issue. Could you clarify what CLA text needs to be included in the PR description?

<!-- gh-comment-id:4480975089 --> @paulxg12 commented on GitHub (May 18, 2026): I'd like to work on this issue. Could you clarify what CLA text needs to be included in the PR description?
GiteaMirror commented 2026-05-21 03:10:57 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (May 18, 2026):

The one that's included by default when you open a PR. Just don't delete it :)

<!-- gh-comment-id:4481031158 --> @Classic298 commented on GitHub (May 18, 2026): The one that's included by default when you open a PR. Just don't delete it :)
GiteaMirror commented 2026-05-21 03:10:58 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (May 19, 2026):

Should be addressed in dev.

<!-- gh-comment-id:4491832997 --> @tjbck commented on GitHub (May 19, 2026): Should be addressed in dev.
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#123716
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?