Empty Proxy Pools: Fail, Wait or Use an Approved Fallback

The rotator removes its last eligible endpoint. What happens to the next job?

That decision should be explicit. An empty list is not a special kind of working proxy. A random-choice exception, a missing metadata field, and a return value of None can each push the next layer down a different path.

For a job that requires an approved proxy route, choose one of these outcomes before dispatch:

• Wait for a known recovery or refresh, within the job's remaining deadline.
• Fail with a specific pool-unavailable result.
• Use a separately configured and approved fallback.

Silently omitting the proxy is another policy entirely. Depending on the client, it can activate an environment default or a direct route. The resulting successful HTTP response can conceal that the required intermediary was never used.

Keep an empty provider response distinct from a pool whose endpoints are all temporarily cooling down. The first may need a discovery-service diagnosis; the second may already have a scheduled recovery time. Re-fetching the same empty list in a tight loop helps neither.

Report the pool state and the decision made, with secrets removed. “No eligible proxy; task stopped” is more actionable than a generic connection error from a route the caller never meant to choose.