TauricResearch/TradingAgents · error · RuntimeError

No available vendor for '{method}'

Error message

No available vendor for '{method}'

What it means

Raised by route_to_vendor() in tradingagents/dataflows/interface.py as the terminal RuntimeError after the vendor loop ends: no vendor returned a value, none reported a clean NoMarketDataError, and no first_error was captured. In practice it means the resolved vendor chain was empty or every vendor failed in a way that recorded nothing — a defensive backstop against falling off the end without a verdict.

Source

Thrown at tradingagents/dataflows/interface.py:262

            f"any configured vendor{reason}. The symbol may be invalid, delisted, "
            f"not covered, or the vendor returned stale data. Do not estimate or "
            f"fabricate values — report that data is unavailable for this symbol."
        )

    # No vendor returned data and none reported clean "no data" — surface the
    # first real error (e.g. the primary vendor's network failure). Optional
    # enrichment categories degrade to a sentinel instead, so flavour data can't
    # abort the run.
    if first_error is not None:
        if category in OPTIONAL_CATEGORIES:
            logger.warning("Optional %s unavailable for %s: %s", category, method, first_error)
            return (
                f"DATA_UNAVAILABLE: optional {category} could not be retrieved "
                f"({first_error}). Proceed without it; do not fabricate values."
            )
        raise first_error

    raise RuntimeError(f"No available vendor for '{method}'")

View on GitHub (pinned to a33fd4c0f1)

Solutions

1. Inspect the registry: from tradingagents.dataflows.interface import VENDOR_METHODS; print(VENDOR_METHODS.get(method)) — an empty/missing dict is the cause
2. Reinstall a consistent package version if registry tables drifted (pip install --force-reinstall tradingagents)
3. If you maintain the fork, ensure every categorized method has at least one vendor entry
4. As a caller, catch RuntimeError around route_to_vendor as a last-resort handler mapping to 'data unavailable'

Example fix

# before
result = route_to_vendor("get_fundamentals", "AAPL")  # registry entry empty
# -> RuntimeError: No available vendor for 'get_fundamentals'

# after
from tradingagents.dataflows.interface import VENDOR_METHODS
assert VENDOR_METHODS.get("get_fundamentals"), "no vendors registered"
result = route_to_vendor("get_fundamentals", "AAPL")

from tradingagents.dataflows.interface import VENDOR_METHODS

def has_any_vendor(method: str) -> bool:
    return bool(VENDOR_METHODS.get(method))

try:
    result = route_to_vendor(method, *args)
except RuntimeError as e:
    if "No available vendor" in str(e):
        logger.error("No vendors registered for %s; registry is inconsistent", method)
        return f"DATA_UNAVAILABLE: {method} has no vendor implementation"
    raise

When it happens

Trigger: VENDOR_METHODS[method] resolving to an empty mapping (registry drift in forks), or control flow reaching the end with all state unset — normal single-vendor failures are captured as first_error and re-raised instead, so end users should rarely see this exact message.

Common situations: Forks/plugins that register a method with an empty vendor dict; exotic exceptions bypassing the recorded handlers; highly defensive code paths after upstream refactors of the router.

Related errors

• Method '{method}' not supported
• Method '{method}' not found in any category
• Configured vendor(s) {explicit} not available for '{method}'

AI-assisted analysis of TauricResearch/TradingAgents@a33fd4c0f1 (2026-08-14). Data as JSON: /api/errors/e23287ed59307adb. Report an issue: GitHub.