mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-07 11:28:35 -05:00
[GH-ISSUE #12977] issue: Abnormal Error when using Web Search #16775
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#16775
Reference in New Issue
Block a user
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?
Originally created by @ReiSuzunami on GitHub (Apr 17, 2025).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/12977
Check Existing Issues
Installation Method
Docker
Open WebUI Version
v0.6.5
Ollama Version (if applicable)
No response
Operating System
server: Debian 12 client: macOS Sequoia
Browser (if applicable)
MS Edge 135.0.3179.73
Confirmation
README.md.Expected Behavior
Web Interface should wait the Web Search Engine(searxng in my case) to return all results, and return an Error only after timeout or other situation.
The reference should be distributed into different sources, not only the first one.
Actual Behavior
Web Interface returns a
TypeError: Failed to fetchin the middle of searching, which did not acturally interrupt the process, but still display a consistent error message beneth the response area.All the references are pointed to the first search result.
Steps to Reproduce
Logs & Screenshots
Browser Logs:
Docker Logs:
Everything went fine but did not see any log corresponding to the
/api/chat/completions. Assue that was caused by a regular keepalive mechanism because the completion process was blocked by the content fetching process.Additional Information
I'm using self-deployed SearXNG and Playwright server to get me search result.
I chose an OpenAI-compatible embedding model to process CJK languages.
@tth37 commented on GitHub (Apr 17, 2025):
Could you share the console log in browser, is there any error messages related to
TypeError: Failed to fetch? (as it seems to be a bug in frontend)The second bug is already identified in #12811
@ReiSuzunami commented on GitHub (Apr 17, 2025):
There is one related console log which I missed before:
I visit my instance by following network structure:
Client --HTTP/2--> CDN --HTTP--> Nginx --HTTP--> Docker ComposeCould the HTTP/2 convertion be a potential problem?
@tth37 commented on GitHub (Apr 17, 2025):
Maybe check Nginx logs?
@ReiSuzunami commented on GitHub (Apr 17, 2025):
There did have a 499 error in the Nginx log, just after a 200 with a similar request. This instance is only used by me so there's no influences from other users.
It seems that a HTTPS URI was sent to the HTTP service?
@tth37 commented on GitHub (Apr 17, 2025):
If you turn off web search, does this
TypeError: Failed to fetchstill exists? btw maybe consider sharing your Nginx configuration and your "cdn" configuration?@ReiSuzunami commented on GitHub (Apr 17, 2025):
No, this only happens when Open-WebUI executes Web Searching.
My Nginx server block:
I used Tencent EdgeOne for CDN and I just configured the HTTP/2 option for visitors and HTTP/1.1 for fetching the source.
@tth37 commented on GitHub (Apr 17, 2025):
What if bypassing tencent proxy, directly access the Nginx service?
@ReiSuzunami commented on GitHub (Apr 17, 2025):
Well the problem seems to disappear when I directly visit the site use HTTP without the CDN. There's nothing with Open-WebUI. I will try to configure it correctly.
@ReiSuzunami commented on GitHub (Apr 18, 2025):
I found the real problem.
/api/chat/completionsis a SUPER LONG request in Web Searching, which includes the full process that LLM generates query and wait for SearXNG to return the results, before the answer started to generate.This time is usually 40-60 seconds on WebSocket when I'm using SearXNG and my CDN regarded that as a timeout. So the error showed up.
When I'm using HTTP Directly, there was no 'timeout' settings so the error would not happen. Also, when I'm making regular conversations(without Web Searching), the 'waiting process' was instant because the answer is genreated directly.
So is there a possibility to optimize this feature? In my case I can change the timeout threshold of my CDN, but there must have situations that sensitive to timeout limit. It would be nice if this process could be optimized!
@tth37 commented on GitHub (Apr 18, 2025):
The response time for
/api/chat/completionsis too long, which in my opinion, is indeed a problem. Because when there is a background WebSocket connection,/api/chat/completionsshould ideally be a function that returns quickly, allowing theprocess_chat_payloadandprocess_chat_responseprocesses to run in the background.Currently, only
process_chat_responseis fully run in the background, whileprocess_chat_payloadremains a synchronous function. I suspect that the design might not have considered thatprocess_chat_payloadcould also take a long time.A possible fix is to also design
process_chat_payloadas an async function that runs in the background, returns the chat completion immediately and updating response status via WebSocket. 🤔 (This seems theoretically possible, but it might require substantial refactoring of thechat_completionhandler)