GiteaMirror commented

Owner

Originally created by @wolfdevmail on GitHub (Oct 13, 2025).

Check Existing Issues

I have searched for any existing and/or related issues.
I have searched for any existing and/or related discussions.
I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.33

Ollama Version (if applicable)

No response

Operating System

Debian 12

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

When uploading a file that cannot be processed, either the upload should be refused, or if accepted, should not stall on loading.

Actual Behavior

When we upload a file, i.e. video files, which are not currently specified to be processed in routers/files.py:process_uploaded_file, the upload succeeds, however, status is never updated for the unprocessed file, because it does not go into either of the if else cases. This leads to issue in get_file_process_status leading to non 200 response after a stall time.
The request to /api/v1/files/.../process/status?stream=true, after 1 min pending time, even for tiny files (because it is irrelevant here), fails with code 500.
It would appear as network latency, or file taking time to upload, but in fact file is already uploaded, the status "pending" of the file, since it was not processed, is the actual issue.

Steps to Reproduce

Start with default config.
Using llama3.2:1b (in my specific test, but probably irrelevant).
Upload video file which is not webm.
While we see the file upload loading, right click, inspect, check the request /api/v1/files/.../process/status?stream=true it would say "pending".

Logs & Screenshots

no console/docker logs available, both irrelevant and do not contain anything.
This happens on backend, the visible results on the front end are:
request:
GET https://{redacted}/api/v1/files/{file_id}/process/status?stream=true (which is sent after the file upload starts)
response (after 1 min):

Error

Sorry, but something went wrong.

</html>

Additional Information

Please note that I understand "we do not need to upload these files if local agent cannot process their contents".

In my implementation, I fixed this by editing routers/files.py inside function process_uploaded_file:
After the code:
elif (not file.content_type.startswith(("image/", "video/"))) or (
request.app.state.config.CONTENT_EXTRACTION_ENGINE == "external"
):
process_file(request, ProcessFileForm(file_id=file_item.id), user=user)

I added:
elif file.content_type.startswith(("image/", "video/")):
log.info(f"Forcing process for {file.content_type}, better fail than stall!")
process_file(request, ProcessFileForm(file_id=file_item.id), user=user)

A safer alternative would be either to change the get_file_process_status to respond differently for this specific case, or to edit process_uploaded_file to take into considerations all possibilities, and if we cannot process the file, we can still make a fake "done" status with content "Unable to process, ... "

Originally created by @wolfdevmail on GitHub (Oct 13, 2025). ### 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 am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.33 ### Ollama Version (if applicable) _No response_ ### Operating System Debian 12 ### 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 When uploading a file that cannot be processed, either the upload should be refused, or if accepted, should not stall on loading. ### Actual Behavior When we upload a file, i.e. video files, which are not currently specified to be processed in routers/files.py:process_uploaded_file, the upload succeeds, however, status is never updated for the unprocessed file, because it does not go into either of the if else cases. This leads to issue in get_file_process_status leading to non 200 response after a stall time. The request to /api/v1/files/.../process/status?stream=true, after 1 min pending time, even for tiny files (because it is irrelevant here), fails with code 500. It would appear as network latency, or file taking time to upload, but in fact file is already uploaded, the status "pending" of the file, since it was not processed, is the actual issue. ### Steps to Reproduce Start with default config. Using llama3.2:1b (in my specific test, but probably irrelevant). Upload video file which is not webm. While we see the file upload loading, right click, inspect, check the request /api/v1/files/.../process/status?stream=true it would say "pending". ### Logs & Screenshots no console/docker logs available, both irrelevant and do not contain anything. This happens on backend, the visible results on the front end are: request: GET https://{redacted}/api/v1/files/{file_id}/process/status?stream=true (which is sent after the file upload starts) response (after 1 min): <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width,initial-scale=1" /> <title>Error</title> </head> <body> <h1>Error</h1> <p>Sorry, but something went wrong.</p> </body> </html> ### Additional Information Please note that I understand "we do not need to upload these files if local agent cannot process their contents". In my implementation, I fixed this by editing routers/files.py inside function process_uploaded_file: After the code: elif (not file.content_type.startswith(("image/", "video/"))) or ( request.app.state.config.CONTENT_EXTRACTION_ENGINE == "external" ): process_file(request, ProcessFileForm(file_id=file_item.id), user=user) I added: elif file.content_type.startswith(("image/", "video/")): log.info(f"Forcing process for {file.content_type}, better fail than stall!") process_file(request, ProcessFileForm(file_id=file_item.id), user=user) A safer alternative would be either to change the get_file_process_status to respond differently for this specific case, or to edit process_uploaded_file to take into considerations all possibilities, and if we cannot process the file, we can still make a fake "done" status with content "Unable to process, ... "