Bing retriever has an unbounded request and propagates transport failures

Summary

BingSearch.search() currently calls the external Bing endpoint without a timeout or request-error guard:

resp = requests.get(url, headers=headers, params=params)

That leaves two reliability gaps in a core retrieval path:

1. an unresponsive Bing endpoint can block a research step indefinitely at the HTTP layer;
2. DNS/connect/read/TLS failures raise requests.RequestException directly into the research pipeline instead of degrading to an empty retriever result, which is the behavior used by several sibling retrievers.

The method also continues parsing non-2xx responses as if they were normal search payloads.

Expected behavior

The Bing retriever should have a bounded request duration and handle transport/HTTP failures consistently with other retrievers.

A narrow fix would be:

try:
    resp = requests.get(url, headers=headers, params=params, timeout=20)
    resp.raise_for_status()
except requests.RequestException as exc:
    self.logger.error("Bing search request failed: %s", exc)
    return []

The existing payload normalization can remain unchanged.

Regression coverage

Focused offline tests can verify:

• requests.get receives a finite timeout;
• a requests.RequestException returns [] rather than propagating;
• a non-2xx response handled by raise_for_status() also degrades to [];
• the existing happy-path result shape is unchanged.

This is a concrete instance of the broader external-call timeout concern in #1764, scoped to one retriever so it can be fixed and tested independently.

I searched the current issue and PR trackers for a Bing request-timeout/error-boundary fix and did not find an existing implementation.

AI-assisted review disclosure: an AI coding assistant was used to inspect the retriever request path and help prepare this report.