fix(web): xAI tool gating and search dispatch fallback

[crazywriter1]

Summary

• Include xai in check_web_api_key() so web_search / web_extract are not gated off when web.backend: xai or only xAI credentials (OAuth / XAI_API_KEY) are present.
• When _get_search_backend() names a registered provider that is not is_available() (e.g. default firecrawl with no Firecrawl creds but xAI configured), fall back to get_active_search_provider() instead of calling search() on the dead backend.

Problem

After the bundled xAI web search plugin landed (a0c031299), two wiring gaps remained in tools/web_tools.py:

1. check_web_api_key() — _is_backend_available("xai") worked, but the helper’s configured/scan lists still listed only the original seven backends. web.backend: xai always evaluated to “not configured,” so the tools never registered.
2. web_search_tool dispatch — Fallback to get_active_search_provider() ran only when the provider was missing or did not support search, not when it was unavailable. Users with only xAI creds often hit the default firecrawl name first and got a Firecrawl configuration error instead of registry resolution picking xAI.

Changes

• tools/web_tools.py — add _WEB_AVAILABILITY_BACKENDS (includes xai); extend check_web_api_key(); gate dispatch on is_available() before delegating.
• tests/tools/test_web_tools_config.py — xAI-only and configured-xai cases for check_web_api_key().
• tests/tools/test_web_providers_xai.py — regression for configured-backend unavailable → active provider fallback.

Test plan

• pytest tests/tools/test_web_tools_config.py::TestCheckWebApiKey -q -o addopts=''
• pytest tests/tools/test_web_providers_xai.py::TestXAIBackendWiring -q -o addopts=''
• Full CI (repo workflow)

Notes

Does not change _get_backend() auto-detect candidate order (xAI intentionally excluded there; see test_xai_not_in_legacy_backend_candidate_chain).

[teknium1]

Thanks for identifying the xAI-only dispatch path. The dispatch issue remains reproducible by inspection on current main: tools/web_tools.py:241-270 intentionally falls back to firecrawl when no backend is configured, while tools/web_tools.py:686-692 falls back to the active registry provider only for a missing or incapable provider—not an unavailable one. The registry would select the available xAI provider in this case (agent/web_search_registry.py:199-219).

Problems

• Do not carry forward the xAI-specific check_web_api_key() whitelist. Current main already has the broader registry-based availability gate at tools/web_tools.py:1050-1085, merged via 0a9d42ce4 / PR fix(web_tools): honor plugin-registered provider availability at the tool gate #57779; replacing it would lose generic plugin-provider support.

Suggested changes

• Salvage the unavailable-provider dispatch fallback and its regression coverage onto the current dispatcher, while retaining the current generalized gate.

Automated hermes-sweeper review.

[crazywriter1]

Thanks for identifying the xAI-only dispatch path. The dispatch issue remains reproducible by inspection on current main: tools/web_tools.py:241-270 intentionally falls back to firecrawl when no backend is configured, while tools/web_tools.py:686-692 falls back to the active registry provider only for a missing or incapable provider—not an unavailable one. The registry would select the available xAI provider in this case (agent/web_search_registry.py:199-219).

Problems

• Do not carry forward the xAI-specific check_web_api_key() whitelist. Current main already has the broader registry-based availability gate at tools/web_tools.py:1050-1085, merged via 0a9d42ce4 / PR fix(web_tools): honor plugin-registered provider availability at the tool gate #57779; replacing it would lose generic plugin-provider support.

Suggested changes

• Salvage the unavailable-provider dispatch fallback and its regression coverage onto the current dispatcher, while retaining the current generalized gate.

Automated hermes-sweeper review.

Thanks @teknium1 Addressed as requested after merging current main:

1. Dropped the xAI-specific check_web_api_key() whitelist. Kept main’s registry-based gate from fix(web_tools): honor plugin-registered provider availability at the tool gate #57779 (0a9d42ce4) so plugin providers stay intact.
2. Kept the unavailable-provider dispatch fallback: if the named backend’s is_available() is false, we fall back to get_active_search_provider() (same path as missing/incapable), plus the regression test.

Ready for another look.

[GottZ]

This was generated by AI during triage.

Summary

Two PRs address the xAI web-tool path but cover distinct causes: #36802 added xAI to the former availability whitelist, while #29425 makes search dispatch reject an unavailable named provider and fall back to the active registry provider, with xAI gate and dispatch regression coverage.

Related pull requests

• #29425 related — (+81/-14) — keep open / merge candidate: The production diff adds the missing unavailable-provider fallback, preventing a default-but-unavailable Firecrawl provider from intercepting xAI-only setups; it also adds regression tests for dispatch and xAI availability gating without replacing the current generalized registry-based gate. This is consistent with the keep_open review on #29425, which specifically requests salvaging the dispatch fix while retaining that generalized gate.
• #36802 [closed] related — (+2/-2) — merged reference implementation: This closed PR only added xAI to the earlier hardcoded check_web_api_key() lists, addressing the original tool-gating gap; contributor discussion records that it was reapplied and merged via #37146 with authorship preserved.

Suggested consolidation

Merge #29425 after confirming the current generalized registry-based check_web_api_key() gate remains intact; its visible implementation change fixes the still-reproducible unavailable-provider dispatch path, while its gate tests provide regression coverage rather than reintroducing the old whitelist. #36802 is not a duplicate of the current #29425 diff and needs no closure action because it is already closed and its change was merged via #37146.

Cross-PR triage: Reviewed 2 pull requests and 0 issues in this complex. Each diff was read against this issue; Assessment working set: 10 kB of PR diffs, 2 kB of issue/PR text, 4 kB of discussion (5 comments), 0 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.