github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-05-08 12:58:11 -05:00
Code Issues 1.3k Packages Projects Releases 126 Wiki Activity

[GH-ISSUE #23101] issue: API call "list files" produces 500 Internal Server Error #35416

New Issue
Closed
opened 2026-04-25 09:37:18 -05:00 by GiteaMirror · 5 comments
GiteaMirror commented 2026-04-25 09:37:18 -05:00
Owner
Copy Link

Originally created by @wsomm on GitHub (Mar 26, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23101

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

Pip Install

Open WebUI Version

0.8.11

Ollama Version (if applicable)

No response

Operating System

Mac Tahoe 26.4

Browser (if applicable)

No response

Confirmation

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

Expected Behavior

Call api/v1/files/ to get a list of all stored files in the OWUI database.

Actual Behavior

HTTP Error 500: Internal Server Error.

Steps to Reproduce

Just call

curl -X GET "http://$OPENWEBUI_BASE_MACHINE:8080/api/v1/files/?page=1&content=true" -H "accept: application/json" -H "Authorization: Bearer $OPENWEBUI_API_KEY"

with the correct $OPENWEBUI_BASE_MACHINE and $OPENWEBUI_API_KEY set in the environment.
Or call from the Swagger interface "list files".

Logs & Screenshots

One call give 50K log files... Not sure if it helps.

Additional Information

New in 0.8.11. 0.8.10 works.

Originally created by @wsomm on GitHub (Mar 26, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/23101 ### 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 Pip Install ### Open WebUI Version 0.8.11 ### Ollama Version (if applicable) _No response_ ### Operating System Mac Tahoe 26.4 ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [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. ### Expected Behavior Call api/v1/files/ to get a list of all stored files in the OWUI database. ### Actual Behavior HTTP Error 500: Internal Server Error. ### Steps to Reproduce Just call curl -X GET "http://$OPENWEBUI_BASE_MACHINE:8080/api/v1/files/?page=1&content=true" -H "accept: application/json" -H "Authorization: Bearer $OPENWEBUI_API_KEY" with the correct $OPENWEBUI_BASE_MACHINE and $OPENWEBUI_API_KEY set in the environment. Or call from the Swagger interface "list files". ### Logs & Screenshots One call give 50K log files... Not sure if it helps. ### Additional Information New in 0.8.11. 0.8.10 works.
GiteaMirror added the bug label 2026-04-25 09:37:18 -05:00
GiteaMirror commented 2026-04-25 09:37:19 -05:00
Author
Owner
Copy Link

@yang1002378395-cmyk commented on GitHub (Mar 26, 2026):

Investigation Needed

This is a regression in v0.8.11. The /api/v1/files/ endpoint returns HTTP 500.

Likely causes:

  1. Database schema migration issue
  2. Missing error handling for edge cases (empty files, corrupted metadata)
  3. Query optimization causing timeout with large file counts

Debug steps:

  1. Check Open WebUI logs: docker logs <container> --tail 100
  2. Check if the issue persists with a fresh database
  3. Try with content=false to isolate the problem

Could you share the error traceback from the server logs? That would help pinpoint the exact failure point.

<!-- gh-comment-id:4136806640 --> @yang1002378395-cmyk commented on GitHub (Mar 26, 2026): ## Investigation Needed This is a regression in v0.8.11. The `/api/v1/files/` endpoint returns HTTP 500. **Likely causes**: 1. Database schema migration issue 2. Missing error handling for edge cases (empty files, corrupted metadata) 3. Query optimization causing timeout with large file counts **Debug steps**: 1. Check Open WebUI logs: `docker logs <container> --tail 100` 2. Check if the issue persists with a fresh database 3. Try with `content=false` to isolate the problem Could you share the error traceback from the server logs? That would help pinpoint the exact failure point.
GiteaMirror commented 2026-04-25 09:37:20 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Mar 26, 2026):

@yang1002378395-cmyk please refrain from "likely causes" ai generated comments. These are not helpful. If you're using AI to analyze issues at least analyze the code or refrain from commenting please

<!-- gh-comment-id:4137482154 --> @Classic298 commented on GitHub (Mar 26, 2026): @yang1002378395-cmyk please refrain from "likely causes" ai generated comments. These are not helpful. If you're using AI to analyze issues at least analyze the code or refrain from commenting please
GiteaMirror commented 2026-04-25 09:37:21 -05:00
Author
Owner
Copy Link

@wsomm commented on GitHub (Mar 26, 2026):

If it helps: This is what claude code gave me as a hint:

0.8.10 — correct:

models/files.py

class FileListResponse(BaseModel):
items: list[FileModel] # ← FileModel: meta: Optional[dict] = None
total: int

FileListResponse holds FileModel objects. FileModel.meta is Optional[dict] — NULL in the database is fine. No coercion happens.

0.8.11 — broken:

models/files.py

class FileListResponse(BaseModel):
items: list[FileModelResponse] # ← changed to FileModelResponse
total: int

class FileModelResponse(BaseModel):
meta: FileMeta # ← required, NOT Optional

get_file_list() still creates list[FileModel] and passes them into FileListResponse(items=...). Pydantic v2 now coerces each FileModel → FileModelResponse at construction time. Since FileModelResponse.meta is required and
FileMeta.sanitize_meta() returns None unchanged when the DB value is NULL, Pydantic raises ValidationError → HTTP 500.

If you need addiitonal information, I cannot provide them the next 24 hours.
But I think the error itself is clear.

<!-- gh-comment-id:4137537455 --> @wsomm commented on GitHub (Mar 26, 2026): If it helps: This is what claude code gave me as a hint: 0.8.10 — correct: #### models/files.py class FileListResponse(BaseModel): items: list[FileModel] # ← FileModel: meta: Optional[dict] = None total: int FileListResponse holds FileModel objects. FileModel.meta is Optional[dict] — NULL in the database is fine. No coercion happens. --- 0.8.11 — broken: #### models/files.py class FileListResponse(BaseModel): items: list[FileModelResponse] # ← changed to FileModelResponse total: int class FileModelResponse(BaseModel): meta: FileMeta # ← required, NOT Optional get_file_list() still creates list[FileModel] and passes them into FileListResponse(items=...). Pydantic v2 now coerces each FileModel → FileModelResponse at construction time. Since FileModelResponse.meta is required and FileMeta.sanitize_meta() returns None unchanged when the DB value is NULL, Pydantic raises ValidationError → HTTP 500. --- If you need addiitonal information, I cannot provide them the next 24 hours. But I think the error itself is clear.
GiteaMirror commented 2026-04-25 09:37:21 -05:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Mar 26, 2026):

Addressed in dev.

<!-- gh-comment-id:4138790687 --> @tjbck commented on GitHub (Mar 26, 2026): Addressed in dev.
GiteaMirror commented 2026-04-25 09:37:22 -05:00
Author
Owner
Copy Link

@Classic298 commented on GitHub (Mar 26, 2026):

16335f866e

<!-- gh-comment-id:4138910240 --> @Classic298 commented on GitHub (Mar 26, 2026): https://github.com/open-webui/open-webui/commit/16335f866ea4cedf00c4971963622fcc1fe02d82
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#35416
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?