ZhuLinsen/daily_stock_analysis · critical · GenerationError
unknown_backend_error
unknown_backend_error
Error message
fallback_backend_failed
What it means
GenerationError with code UNKNOWN_BACKEND_ERROR raised at stage 'fallback' when the primary backend already raised a GenerationError (exc) and the subsequent fallback backend attempt failed with an unexpected non-GenerationError exception (fallback_exc). The 'reason' detail is 'fallback_backend_failed'; the error preserves both the primary error and the raw fallback exception in details for diagnosis. retryable and fallbackable are both False because the chain is exhausted.
Solutions
- Inspect details['fallback_error'] / the chained exception to identify what the fallback backend actually threw and fix that root cause first.
- Verify the fallback backend's credentials, model list, and dependencies are complete — partial fallback config is the most common cause.
- If the primary error (details['primary_error']) is itself retryable, fix or retry the primary path rather than relying on the broken fallback.
- As a last resort, add another healthy fallback backend or disable the broken one so the chain degrades cleanly.
Defensive patterns
Strategy: fallback
Try / catch
from src.analyzer import GenerationError
try:
result = run_generation(...)
except GenerationError as e:
if e.details.get("reason") == "fallback_backend_failed":
log_primary = e.details["primary_error"]
log_fallback = e.details.get("fallback_exc")
# both backends broken: do not retry blindly; alert ops / degrade to cached report
raise Prevention
- Health-check every configured backend at startup, not just the primary.
- Keep fallback backend credentials and deps fully configured — partial fallback config is the top cause.
- Preserve and log details['primary_error'] to avoid fixing the wrong backend.
When it happens
Trigger: Generation with a primary + fallback backend configured (e.g. litellm primary, another provider fallback) where the primary fails with a structured GenerationError AND the fallback attempt throws an arbitrary exception (network TypeError, missing dependency, bad config) that is not itself a GenerationError.
Common situations: Fallback provider env vars not configured (key missing -> AttributeError/KeyError in its client); a version change in the fallback SDK raising a new exception type; transient network outage hitting both backends where the fallback fails before producing a structured error.
Related errors
AI-assisted analysis of ZhuLinsen/daily_stock_analysis@5159bd72e8 (2026-08-15).
Data as JSON: /api/errors/076c3038b1a82868.
Report an issue: GitHub.
Appendix: source
Thrown at src/analyzer.py:3062
"reason": "fallback_backend_failed",
"primary_error": {
"error_code": exc.error_code.value,
"backend": exc.backend,
"provider": exc.provider,
"stage": exc.stage,
"details": exc.details,
},
"fallback_error": {
"error_code": fallback_exc.error_code.value,
"backend": fallback_exc.backend,
"provider": fallback_exc.provider,
"stage": fallback_exc.stage,
"details": fallback_exc.details,
},
},
) from fallback_exc
except Exception as fallback_exc:
raise GenerationError(
error_code=GenerationErrorCode.UNKNOWN_BACKEND_ERROR,
stage="fallback",
retryable=False,
fallbackable=False,
backend=fallback_backend_id,
provider=fallback_backend_id,
details={
"reason": "fallback_backend_failed",
"primary_error": {
"error_code": exc.error_code.value,
"backend": exc.backend,
"provider": exc.provider,
"stage": exc.stage,
"details": exc.details,
},
"fallback_error": str(fallback_exc),
},
) from fallback_excView on GitHub (pinned to 5159bd72e8)