open-webui/oikb

Fork 0

mirror of https://github.com/open-webui/oikb.git synced 2026-11-05 01:27:25 +00:00

{id} no longer inlines files (same root cause as #89) #56

New issue

Open

opened 2026-10-18 21:13:57 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-18 21:13:57 +00:00

Owner

Originally created by @silentoplayz on GitHub (Aug 1, 2026).
Original GitHub issue: https://github.com/open-webui/oikb/issues/91

Summary

oikb status crashes with TypeError: object of type 'NoneType' has no len() and oikb ls prints (empty) when pointed at a populated Knowledge Base on a current Open WebUI dev build (v0.11.0, image 2026-08-01). Sync itself works fine. The root cause is that newer Open WebUI no longer inlines the file list in GET /api/v1/knowledge/{id} (the web UI now fetches files from a paginated endpoint, GET /api/v1/knowledge/{id}/files?page=1), so the files field oikb reads comes back as null. This is very likely the same root cause as the validate --deep crash in #89 and the NoneType has no len() part of #53.

Environment

oikb 0.4.0 (ghcr.io/open-webui/oikb:latest), daemon mode, GitHub connector
Open WebUI v0.11.0 (ghcr.io/open-webui/open-webui:dev, image built 2026-08-01, digest sha256:f3eef6c272f9...)
The affected Knowledge Base contains 408 files and syncs correctly (hourly diffs report 408 unchanged)

Steps to reproduce

Run Open WebUI :dev (v0.11.0 or the current dev image).
Sync any source into a Knowledge Base with oikb 0.4.0 (sync works; files land and link correctly).
Run oikb status --kb-id <kb id>.
Run oikb ls --kb-id <kb id>.

Expected

status reports the KB name and file count; ls lists the synced files.

Actual

$ oikb status --kb-id e1c8e711-...
Traceback (most recent call last):
  ...
  File "/app/src/oikb/cli.py", line 770, in status
    file_count = len(files)
                 ^^^^^^^^^^
TypeError: object of type 'NoneType' has no len()

$ oikb ls --kb-id e1c8e711-...
(empty)

Both commands go through client.py::list_kb_files, which calls GET /knowledge/{kb_id} and reads the inline files field. On current dev that field is null for every KB (verified directly against the API: a KB with 408 linked files returns files: null, while the web UI populates its file list from GET /api/v1/knowledge/{id}/files?page=1&directory_id=).

Suggested fix

In list_kb_files, try the paginated GET /knowledge/{id}/files endpoint first and fall back to the legacy inline files field for older servers.
Independently, guard the len(files) sites (cli.py:770 in status, and presumably the equivalent in validate --deep, see #89) with files or [] so an unexpected null degrades to "0 files" instead of a traceback.

Additional context

Likely duplicates/relatives: #89 (validate --deep NoneType crash) and the crash half of #53 (reported against the SharePoint connector, but the traceback is the same len(files) on None).
Sync, diff, cleanup, and reset are unaffected because they use the newer /sync/* endpoints rather than the inline files field.
This will affect all oikb users once the current Open WebUI dev branch ships in a stable release, not just people running :dev.

This report was prepared with AI assistance; all observations were verified against the live instances described above.

Originally created by @silentoplayz on GitHub (Aug 1, 2026). Original GitHub issue: https://github.com/open-webui/oikb/issues/91 ## Summary `oikb status` crashes with `TypeError: object of type 'NoneType' has no len()` and `oikb ls` prints `(empty)` when pointed at a populated Knowledge Base on a current Open WebUI dev build (v0.11.0, image 2026-08-01). Sync itself works fine. The root cause is that newer Open WebUI no longer inlines the file list in `GET /api/v1/knowledge/{id}` (the web UI now fetches files from a paginated endpoint, `GET /api/v1/knowledge/{id}/files?page=1`), so the `files` field oikb reads comes back as `null`. This is very likely the same root cause as the `validate --deep` crash in #89 and the `NoneType has no len()` part of #53. ## Environment - oikb 0.4.0 (`ghcr.io/open-webui/oikb:latest`), daemon mode, GitHub connector - Open WebUI v0.11.0 (`ghcr.io/open-webui/open-webui:dev`, image built 2026-08-01, digest `sha256:f3eef6c272f9...`) - The affected Knowledge Base contains 408 files and syncs correctly (hourly diffs report `408 unchanged`) ## Steps to reproduce 1. Run Open WebUI `:dev` (v0.11.0 or the current dev image). 2. Sync any source into a Knowledge Base with oikb 0.4.0 (sync works; files land and link correctly). 3. Run `oikb status --kb-id <kb id>`. 4. Run `oikb ls --kb-id <kb id>`. ## Expected `status` reports the KB name and file count; `ls` lists the synced files. ## Actual ``` $ oikb status --kb-id e1c8e711-... Traceback (most recent call last): ... File "/app/src/oikb/cli.py", line 770, in status file_count = len(files) ^^^^^^^^^^ TypeError: object of type 'NoneType' has no len() $ oikb ls --kb-id e1c8e711-... (empty) ``` Both commands go through `client.py::list_kb_files`, which calls `GET /knowledge/{kb_id}` and reads the inline `files` field. On current dev that field is `null` for every KB (verified directly against the API: a KB with 408 linked files returns `files: null`, while the web UI populates its file list from `GET /api/v1/knowledge/{id}/files?page=1&directory_id=`). ## Suggested fix - In `list_kb_files`, try the paginated `GET /knowledge/{id}/files` endpoint first and fall back to the legacy inline `files` field for older servers. - Independently, guard the `len(files)` sites (`cli.py:770` in `status`, and presumably the equivalent in `validate --deep`, see #89) with `files or []` so an unexpected `null` degrades to "0 files" instead of a traceback. ## Additional context - Likely duplicates/relatives: #89 (`validate --deep` NoneType crash) and the crash half of #53 (reported against the SharePoint connector, but the traceback is the same `len(files)` on `None`). - Sync, diff, cleanup, and reset are unaffected because they use the newer `/sync/*` endpoints rather than the inline `files` field. - This will affect all oikb users once the current Open WebUI dev branch ships in a stable release, not just people running `:dev`. This report was prepared with AI assistance; all observations were verified against the live instances described above.

bsakaguchi commented

2026-10-18 21:13:58 +00:00

Author

Owner

@brownhouse commented on GitHub (Sep 19, 2026):

Title: sync also crashes with 'NoneType' object has no attribute 'get' (0.5.0) -- #91 said sync was unaffected, but it now is too

Related: #91, #89

#91 diagnosed the root cause (newer Open WebUI no longer inlines the
file list in GET /api/v1/knowledge/{id}, so files comes back
null) and specifically noted:

Sync, diff, cleanup, and reset are unaffected because they use the
newer /sync/* endpoints rather than the inline files field.

That's no longer true for me on 0.5.0. oikb sync (and oikb sync -v,
no extra detail shown) now fails outright:

oikb sync -v

────────────────────────────────────────
Syncing: E:\Obsidian\jasonlbrown → <kb-id>
  Failed: 'NoneType' object has no attribute 'get'

oikb status --kb-id <kb-id> still crashes the same way #91 describes
(TypeError: object of type 'NoneType' has no len() at
oikb/cli.py:770), consistent with that diagnosis.

pip show oikb confirms I'm on the latest available version (0.5.0),
so this isn't fixed by upgrading yet.

Environment: Windows, Python 3.14, Open WebUI instance running
locally, same setup as my earlier report in #60.

Re: the suggested fix in your original writeup (paginated
GET /knowledge/{id}/files fallback in list_kb_files, plus
guarding the len(files) sites with files or []) -- that targets
the status/validate --deep path specifically. Per your own
diagnosis, sync uses the separate /sync/* endpoints, so I'm not
sure whether sync failing now is the same underlying null issue
surfacing somewhere in those endpoints too, or a distinct regression.
Flagging in case the suggested fix doesn't also cover this.

Happy to test a patch or provide more logs if useful.

@brownhouse commented on GitHub (Sep 19, 2026): Title: `sync` also crashes with `'NoneType' object has no attribute 'get'` (0.5.0) -- #91 said sync was unaffected, but it now is too Related: #91, #89 #91 diagnosed the root cause (newer Open WebUI no longer inlines the file list in `GET /api/v1/knowledge/{id}`, so `files` comes back `null`) and specifically noted: > Sync, diff, cleanup, and reset are unaffected because they use the > newer `/sync/*` endpoints rather than the inline files field. That's no longer true for me on 0.5.0. `oikb sync` (and `oikb sync -v`, no extra detail shown) now fails outright: ``` oikb sync -v ──────────────────────────────────────── Syncing: E:\Obsidian\jasonlbrown → <kb-id> Failed: 'NoneType' object has no attribute 'get' ``` `oikb status --kb-id <kb-id>` still crashes the same way #91 describes (`TypeError: object of type 'NoneType' has no len()` at `oikb/cli.py:770`), consistent with that diagnosis. `pip show oikb` confirms I'm on the latest available version (0.5.0), so this isn't fixed by upgrading yet. Environment: Windows, Python 3.14, Open WebUI instance running locally, same setup as my earlier report in #60. Re: the suggested fix in your original writeup (paginated `GET /knowledge/{id}/files` fallback in `list_kb_files`, plus guarding the `len(files)` sites with `files or []`) -- that targets the `status`/`validate --deep` path specifically. Per your own diagnosis, `sync` uses the separate `/sync/*` endpoints, so I'm not sure whether `sync` failing now is the same underlying `null` issue surfacing somewhere in those endpoints too, or a distinct regression. Flagging in case the suggested fix doesn't also cover this. Happy to test a patch or provide more logs if useful.

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

open-webui/oikb#56

No description provided.

Rows
Columns