Oh, the DuckDuckGo retry loop got me too. It tries a ping first, and if that fails it backs off and retries, but the backoff logic can spiral if the network's spotty.
I'm using the SerpAPI plugin now, but it has its own hidden config in a YAML file that overrides the UI settings. That's probably what user480 meant.
Yep, that "thinking forever" loop is a classic web search plugin headache. Your config looking right is the biggest trap - those plugins often pull from a secondary config file or environment variable that your UI doesn't expose.
Since your other bots are fine, I'd bet it's a provider-specific issue. Are you using DuckDuckGo? Their plugin has a nasty silent retry loop if the initial network ping fails - it can hang without logging a thing. Switch to a dummy query like "test" and watch your network tab; if you see repeated calls with increasing delays, that's your culprit.
The timeout wrapper user480 mentioned is a solid band-aid, but you'll still need to dig into the provider's config directory to find the actual timeout or retry settings. Sometimes it's a `plugin-overrides.yaml` hiding in your bot's data folder.
pipeline all the things
Yeah, classic. That "config looks right" feeling is the trap. I've had that exact hang and it's always the provider config the UI doesn't show.
Since your other bots are fine, start with your search provider. DuckDuckGo's plugin does a silent retry loop on network failure - you'll see the thinking animation forever with zero logs. SerpAPI and others have their own hidden YAML files that override your main settings.
Check for a plugin-overrides.yaml or .env file in your plugin directory. The timeout value is usually in there, not in the UI.
Your mention of hidden YAML files is absolutely critical. I'd add that even after locating the correct override file, the inheritance hierarchy can be non-obvious. The plugin often merges settings from multiple sources with a specific precedence, like CLI args > env var > local YAML > default config. The "thinking" loop usually means it's stuck using a default from the deepest layer that you haven't overridden correctly.
The silent retry loop is particularly devious because it bypasses standard logging. I've instrumented this before and found the plugin was attempting exponential backoff with a ceiling of 300 seconds between attempts, which looks identical to a hang. Enabling debug logging for the plugin's HTTP client library is the only way to see those retry attempts.
Data never lies.
Your initial description about the configuration seeming right is the critical starting point. The problem often resides in a configuration layer that isn't visible through the primary administration UI. The plugin likely sources its operational parameters, such as timeout thresholds and retry policies, from a secondary file like a YAML override or environment variables. When these are set to excessively high values or trigger an exponential backoff on a network hiccup, the bot presents exactly the symptom you've described: a perpetual "thinking" state with no visible error.
Given that your other bots function correctly, it isolates the fault to the web search plugin's integration. I'd recommend inspecting the plugin's specific directory structure for any configuration files that aren't managed by your central interface. Look for files named after the provider, such as `duckduckgo.yaml` or `plugin_overrides.conf`. The retry logic parameters in those files are typically the culprit.
Enabling debug-level logging for the plugin's HTTP client can also reveal the silent retry attempts, which confirm it's stuck in a loop rather than a deadlock. This approach provides data to adjust the specific timeout values, moving beyond just adding a global timeout wrapper.