mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-07 19:38:46 -05:00
feat: Ability to Select Web Search Threading Method #5281
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/open-webui#5281
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 @rlabusiness on GitHub (May 22, 2025).
Check Existing Issues
Problem Description
In 0.6.6, the following was introduced:
“🚀 Optimized Faster Web Search & Multi-Threaded Queries: Enjoy dramatically faster web search and RAG (retrieval augmented generation) with revamped multi-threaded search—get richer, more accurate results in less time.”
I use duckduckgo as my provider, and since this change was introduced, I’m getting failed queries a lot - the messages in the logs indicate I’m being rate-limited by DuckDuckGo, but that didn’t seem to be the case at all in 0.6.5 and prior.
Desired Solution you'd like
Whatever the behavior difference is between these versions, I’d like to be able to choose the old method so that I don’t hit the rate limit. Either that, or (even better), fix the behavior that is triggering the rate limit in the first place so that all can benefit from the faster performance. Not sure if they’re mutually exclusive though.
RELATED: Give an option for the admin to enable displaying the underlying errors when the error message is displayed (default to OFF). Although not all admins would want this ON by default, having more information in context would be useful for troubleshooting as an admin or even with trusted users. In this instance, the information about being rate limited would be included either in the error toast or in a separate window/modal that could be displayed when the user clicks on the error toast (preferred).
Alternatives Considered
Currently I’ve locked the production environment to version 0.6.5 and can’t upgrade because Web Search is useless for me in the later versions.
I don’t want to dig into the code and manage my own copy with the old functionality, but I guess that could be an alternative. Sounds painful though.
I’ve played with different levels of ”Search Result Count” and “Concurrent Requests”, all the way up to 24 and 48, respectively. Perhaps playing with these more might help me discover a set of parameters that might give consistent behavior. But the fact remains that this didn’t seem to be a problem in 0.6.5 and prior.
Additional Context
No response
@tth37 commented on GitHub (May 22, 2025):
#14107
@tth37 commented on GitHub (May 22, 2025):
Are you sure that v0.6.6 is the first version where the issue appeared?
@tth37 commented on GitHub (May 22, 2025):
The
RateLimitMixincurrently only applies to web loaders. Since v0.6.6 introduced parallel web searching, the rate limit should likely be extended to cover those operations as well@rlabusiness commented on GitHub (May 22, 2025):
@tth37 I'm not 100% certain. I upgraded and discovered this behavior a while back (sometime between 0.6.6 and 0.6.8, I believe). I do think it was 0.6.6 though, because I rolled back to 0.6.5 after testing and not being happy with the web search behavior). But it could have been 0.6.8. If I have time over the next few days, I might be able to stand up a separate instance to confirm.