fix(fallback): resolve api_key_env in fallback chain entries (carve-out of #22665)#22856
Merged
Conversation
…ut of #22665) Fallback chain entries with 'api_key_env: ENV_VAR_NAME' weren't being resolved by either the init-time fallback path (line ~1660) or the runtime _try_activate_fallback path (line ~8045). Only literal 'api_key' was honored; the snake_case 'api_key_env' alias documented elsewhere in the config was silently dropped, so a 'provider: custom' fallback with base_url + api_key_env worked as primary but failed as fallback with 'no endpoint credentials found' / 401. Adds 'or fb.get("api_key_env")' to the existing 'key_env' lookup in both call sites, with empty-string-to-None coercion so unset env vars don't poison the resolver. Salvage of #22665's fallback portion. The original PR also bundled gateway-degrade-on-no-adapters changes (those land via the carve-out in #22853 which is the same code) and run_agent.py memory-nudge counter hydration (issue #22357 territory, not mentioned in the title). Drops both bundled pieces; keeps just the api_key_env fix. Closes #5392.
Contributor
🔎 Lint report:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Salvage of #22665's fallback portion — fallback chain entries with
api_key_env: ENV_VAR_NAMEare now resolved correctly at both init time and runtime.Root cause
run_agent.pyhad two places (init-time fallback chain construction at line ~1660, runtime_try_activate_fallbackat line ~8045) that readfb.get("key_env")but not the documented snake_case aliasfb.get("api_key_env"). So aprovider: customfallback withbase_url+api_key_env: GOOGLE_API_KEYworked as primary (where the normal_normalize_custom_provider_entryruns and maps the alias) but failed as fallback with "no endpoint credentials found" → 401.Changes (carve-out from #22665)
run_agent.py(~lines 1660 and 8045): addor fb.get("api_key_env")to the existingkey_envlookup in both call sites. Empty-string-to-None coercion preserved so unset env vars don't poison the resolver.tests/run_agent/test_fallback_model.py: 3 regression tests inTestFallbackKeyEnvResolutioncovering both call sites + missing-env case.Carve-out rationale
The original PR #22665 by @wesleysimplicio bundled this api_key_env fix with two unrelated changes:
This carve-out keeps just the title-described api_key_env work.
Validation
Closes #5392 via salvage.