a year ago
I'm hosting an Open Web UI, multi-AI platform. All has been working fine except for when I try to upload a 25MB+ .csv it seems to timeout:
2025-05-08 12:40:13.914 | INFO | open_webui.routers.files:upload_file:91 - file.content_type: text/csv - {} 2025-05-08 12:41:39.530 | INFO | open_webui.routers.retrieval:save_docs_to_vector_db:885 - save_docs_to_vector_db: document 25mb.csv file-f368b784-a7c2-4e60-8d20-70bd033d8020 - {} 2025-05-08 12:41:39.586 | INFO | open_webui.routers.retrieval:save_docs_to_vector_db:910 - Using token text splitter: cl100k_base - {} 2025-05-08 12:42:22.215 | INFO | open_webui.routers.retrieval:save_docs_to_vector_db:968 - adding to collection file-f368b784-a7c2-4e60-8d20-70bd033d8020 - {}
My FastAPI application processes uploaded files, and this processing (embedding, DB save) takes over 2 minutes for a 25MB file, causing requests to time out. My logs show the file upload completes, and the timeout occurs during server-side processing. Is it possible to increase the request timeout for my service?
2 Replies
a year ago
Hey jarrydanderson-kepler, this is most likely not related to Railway but your ASGI/WSGI, such as uvicorn/gunicorn. Try increasing the timeout of your ASGI/WSGI and check if it makes a difference.
7 days ago
For anyone still running into this: current Open WebUI has a concrete alternative to keeping the upload request open while embeddings are generated.
I checked the released v0.11.4 source. POST /api/v1/files/?process=true&process_in_background=true accepts the multipart upload, queues processing through BackgroundTasks and returns the file record. Both flags default to true in that release. A custom client can retain the returned id and poll GET /api/v1/files/{id}/process/status until status is completed or failed; don't treat the initial upload response as completed indexing.
Pinned source:
https://github.com/open-webui/open-webui/blob/v0.11.4/backend/open_webui/routers/files.py#L280
https://github.com/open-webui/open-webui/blob/v0.11.4/backend/open_webui/routers/files.py#L435
https://github.com/open-webui/open-webui/blob/v0.11.4/backend/open_webui/routers/files.py#L624
If your installation predates that implementation, check the installed version and test a supported upgrade on a backed-up copy. If you already have this implementation, inspect which request actually fails: file upload, processing-status stream, or a separate knowledge/indexing call. Also check whether your client explicitly sends process_in_background=false. Uploading the bytes still takes time; background processing doesn't eliminate memory pressure or embedding-provider errors.
On the Railway side, today's documented limits are 15 minutes total for a flowing HTTP request, 5 minutes without data, and 5 minutes to finish uploading a request body. Therefore the roughly 2-minute timeline in the original logs does not by itself identify a Railway edge limit. Capture the failing HTTP status and duration and correlate them with the application/worker logs before adjusting a timeout.
https://docs.railway.com/networking/public-networking/specs-and-limits
This is an AI-assisted, source-verified update for current releases, not a reproduction of the May 2025 failure or a test on your deployment.