Skip to content

fix: stop re-upload loop for files rejected during server-side ingestion (#106) - #110

Open
julianlucks wants to merge 3 commits into
open-webui:mainfrom
digital-at-work:fix/permanent-upload-failure-skip
Open

fix: stop re-upload loop for files rejected during server-side ingestion (#106)#110
julianlucks wants to merge 3 commits into
open-webui:mainfrom
digital-at-work:fix/permanent-upload-failure-skip

Conversation

@julianlucks

Copy link
Copy Markdown

Fixes #106.

When Open WebUI rejects a file during ingestion, it is never linked to the KB, so /sync/diff reports it as "added" on every subsequent sync and oikb re-uploads it on every cycle. Every upload creates a new file record and physical copy server-side, which accumulates unboundedly (orphaned records, disk growth).

There are two rejection channels, both handled:

  • Synchronous: the upload POST itself returns 4xx → recorded immediately in the state DB.
  • Asynchronous (dominant): uploads return HTTP 200 while ingestion runs in the background; processing errors are swallowed server-side (file status failed, or processed but never linked). Accepted uploads are now tracked (checksum + file id). When the diff reports a tracked file again, oikb checks GET /files/{id}/process/status instead of re-uploading:
    • failed → recorded as permanent failure, skipped
    • completed but unlinked → the existing file is re-linked in place (no second copy)
    • pending/processing → skipped for that run, checked again next run
    • gone (404) → untracked and re-uploaded normally

Notes:

  • Auth failures (401/403) are deliberately never recorded, so config problems keep surfacing as errors on every run instead of being silently skipped.
  • A changed source checksum is always retried (records are keyed with the checksum).
  • Successful uploads clear any previous failure record.
  • Tracked uploads that the diff no longer reports are untracked again, so the table stays small.
  • New oikb failures command (--kb-id, --clear, --json) to inspect/reset recorded rejections.
  • Sync results gained skipped_failed / skipped_pending counters (CLI summary + daemon dry-run response).

Test plan

  • Unit-level: stubbed connector + client covering both channels (sync 4xx, async failed, pending→linked, completed-unlinked→re-link, re-link rejected→permanent)
  • Verified against a live Open WebUI instance with a real file that always fails ingestion (empty-content rejection): one final upload, status-detected on the next sync, skipped from then on — no further file records created server-side

…pen-webui#106)

When Open WebUI rejects a file during ingestion (4xx, e.g. duplicate or
empty content), it is never linked to the KB, so every subsequent
sync/diff reports it as 'added' and oikb re-uploads it on every cycle.
Each upload creates a new file record + physical copy server-side, which
accumulates unboundedly (orphaned records, disk exhaustion).

Record 4xx upload failures in the state DB (failed_file table, keyed by
kb_id/path/filename with the checksum) and skip matching manifest entries
on subsequent syncs until the source checksum changes. Auth failures
(401/403) are deliberately not recorded so config problems keep
surfacing. Successful uploads clear the record. New 'oikb failures'
command lists/clears the records (--clear re-enables retries).
…-webui#106)

Uploads return HTTP 200 while ingestion runs in the background; Open
WebUI swallows processing errors (file status 'failed', or never linked
to the KB). Every such file reappears as 'added' in each sync/diff and
was re-uploaded on every cycle — creating a new server-side file record
and physical copy each time.

Record accepted uploads (checksum + server file id) in the state DB. On
subsequent syncs, files the diff reports again are status-checked via
GET /files/{id}/process/status instead of re-uploaded:
- failed            → recorded as permanent failure, skipped
- completed, unlinked → re-link the existing file (covers duplicate
                      content rejections and manual KB removals)
- pending/processing → skipped this run, checked again next run
- gone (404)        → untracked, re-uploaded normally
Tracked files no longer reported by the diff are untracked again.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug : Failed Open WebUI ingestion causes repeated uploads and disk exhaustion during Google Drive sync

1 participant