issue: Websearch can lock you out on a failure #4785

New Issue

GiteaMirror · 2025-11-11T16:03:09-06:00

GiteaMirror commented

2025-11-11 16:03:09 -06:00

Originally created by @geiseri on GitHub (Apr 9, 2025).

Check Existing Issues

I have searched the existing issues and discussions.
I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.2

Ollama Version (if applicable)

No response

Operating System

Ubuntu 24.04

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 listed steps to reproduce the bug in detail.

Expected Behavior

When I get a 4XX error from a websearch rest call it will fail or at least throttle further requests to the endpoint.

Actual Behavior

On a 429 Client Error: Too Many Requests error the caller continues to hit the search endpoint until all search queries are exhausted.

Steps to Reproduce

This is a bit funky since I am using google personal search, but the logic applies to the other search providers.

But hit your API quota and then issue a further search. You will see "No search results found" in the UI but it will still generate a response.

Logs & Screenshots

fastapi.exceptions.HTTPException: 400: 429 Client Error: Too Many Requests for url: https://www.googleapis.com/cus

This is what I see, so in theory specific 4xx errors could be handled accordingly. The "No search results found" message could be augmented with a sanitized reason.

Additional Information

Since the websearch can be augmented by the local RAG maybe the best approach would be to skip further calls to the endpoint and then show the actual reason instead of "No search results found". That way smooth brained individuals like me don't keep hitting the Regenerate button over and over again ;)

Originally created by @geiseri on GitHub (Apr 9, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.2 ### Ollama Version (if applicable) _No response_ ### Operating System Ubuntu 24.04 ### 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 listed steps to reproduce the bug in detail. ### Expected Behavior When I get a 4XX error from a websearch rest call it will fail or at least throttle further requests to the endpoint. ### Actual Behavior On a `429 Client Error: Too Many Requests` error the caller continues to hit the search endpoint until all search queries are exhausted. ### Steps to Reproduce This is a bit funky since I am using google personal search, but the logic applies to the other search providers. But hit your API quota and then issue a further search. You will see "No search results found" in the UI but it will still generate a response. ### Logs & Screenshots ``` fastapi.exceptions.HTTPException: 400: 429 Client Error: Too Many Requests for url: https://www.googleapis.com/cus ``` This is what I see, so in theory specific 4xx errors could be handled accordingly. The "No search results found" message could be augmented with a sanitized reason. ### Additional Information Since the websearch can be augmented by the local RAG maybe the best approach would be to skip further calls to the endpoint and then show the actual reason instead of "No search results found". That way smooth brained individuals like me don't keep hitting the `Regenerate` button over and over again ;)

GiteaMirror added the bug label 2025-11-11 16:03:09 -06:00

GiteaMirror closed this issue

2025-11-11 16:03:09 -06:00

GiteaMirror referenced this issue

2025-11-11 17:51:49 -06:00

[PR #4785] [MERGED] chore(deps): bump markdown from 3.6 to 3.7 in /backend #8357

Sign in to join this conversation.