fix(fallback): resolve base_url from custom_providers when fallback entry has none (#15743)#15756
Closed
briandevans wants to merge 1 commit into
Closed
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes provider fallback activation so that when a fallback entry references a provider defined in custom_providers (or providers) but omits an inline base_url, the fallback resolves and uses the custom provider’s configured endpoint instead of silently inheriting the primary provider’s base_url (issue #15743).
Changes:
- Extend
_try_activate_fallback()to consult named custom provider config forbase_url/API key hints when the fallback entry provides neither. - Ensure inline fallback
base_urlcontinues to take precedence (no custom provider lookup in that case). - Add targeted regression tests covering the happy path, precedence behavior, and lookup failure resilience.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
run_agent.py |
Adds a guarded lookup to pull base_url/key hints from named custom provider config before constructing the fallback client. |
tests/run_agent/test_provider_fallback.py |
Adds regression tests verifying correct endpoint selection, precedence, and graceful handling of lookup errors. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
1 task
…lback entry (NousResearch#15743) When a fallback_providers entry names a provider defined in custom_providers but does not supply an inline base_url, _try_activate_fallback() was silently sending the request to the primary provider's endpoint instead of the custom one. Fix: before calling resolve_provider_client, look up the provider name in custom_providers via _get_named_custom_provider() and propagate its base_url (and api_key / key_env) as explicit hints. The lookup is wrapped in a broad except so a config-load failure degrades gracefully to the existing named-provider path instead of aborting the fallback chain. Adds three new tests in TestCustomProviderFallbackBaseUrl covering: - base_url pulled from custom_providers when absent from fallback entry - inline base_url on the fallback entry skips the lookup entirely - lookup failure does not crash fallback activation Closes NousResearch#15743 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
03e2823 to
380b25a
Compare
This was referenced May 1, 2026
Contributor
Author
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
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.
Problem
When
fallback_providersreferences a provider defined incustom_providersbut does not supply an inlinebase_url,_try_activate_fallback()passedexplicit_base_url=Nonetoresolve_provider_client(). The resolution then fell through to the primary provider's endpoint, silently misdirecting the fallback request.Reported in #15743.
Root cause
_try_activate_fallback()only sourcedfb_base_url_hintfrom the fallback entry's ownbase_urlfield and fromKNOWN_PROVIDERS. Namedcustom_providersentries were never consulted, so any provider whose connectivity lives entirely incustom_providers(no built-in entry) produced aNonehint.Fix
Before calling
resolve_provider_client(), when neitherfb_base_url_hintnorfb_api_key_hintis set, attempt a lookup via_get_named_custom_provider(fb_provider)and propagatebase_url,api_key, andkey_envas explicit hints:The entire block is wrapped in
except Exception: passso a config-load failure degrades gracefully —resolve_provider_client()still runs with whatever it can derive from the provider name alone, exactly as before.Precedence is preserved: the lookup only runs when both hints are empty. An inline
base_urlin the fallback entry always takes priority.Tests
Three new tests in
TestCustomProviderFallbackBaseUrl(appended totests/run_agent/test_provider_fallback.py):test_custom_provider_base_url_used_when_not_in_fallback_entryexplicit_base_urlis the custom provider's URL;agent.base_urlis updated;agent.providermatchestest_inline_base_url_takes_precedence_over_custom_providers_lookup_get_named_custom_provideris not called when inlinebase_urlis presenttest_custom_provider_lookup_failure_does_not_crash_fallbackRuntimeErrorfrom the lookup does not abort fallback activationAll 22 tests in the file pass (
22 passed).Checklist
base_urlcontinues to take precedence (no behaviour change for existing configs)custom_providersCloses #15743