fix(setup+auxiliary): custom endpoint loses config after setup, and auxiliary ignores active provider#3442
Closed
Mibayy wants to merge 3 commits into
Closed
fix(setup+auxiliary): custom endpoint loses config after setup, and auxiliary ignores active provider#3442Mibayy wants to merge 3 commits into
Mibayy wants to merge 3 commits into
Conversation
When the main agent uses a named custom provider (e.g. custom:local saved in config.yaml), _resolve_custom_runtime() was bypassing it entirely. The old code hardcoded requested="custom", which _get_named_custom_provider explicitly rejects - it returns None when requested_norm == "custom". The auxiliary path then fell back to env-var resolution (OPENAI_BASE_URL), which can carry different or missing credentials. Fix: - Call resolve_requested_provider() first to get the same provider the main agent is using (reads config.yaml / HERMES_INFERENCE_PROVIDER). - Resolve with that active provider name so named custom providers are honoured via _get_named_custom_provider. - Fall back to requested="custom" only when the active provider is not itself a custom endpoint (e.g. nous, openrouter), preserving existing behaviour for env-driven OPENAI_BASE_URL setups. - Add debug logging of which credential source was selected (no secrets). Fixes: NousResearch#3410
…ropic_client test_vision_auto_falls_back_to_custom_endpoint set OPENAI_BASE_URL to test the custom-endpoint fallback path, but the vision auto chain tries anthropic before custom. Without mocking build_anthropic_client, the test hit the real SDK which fails with 'proxies=' on newer anthropic SDK versions. Fix: patch build_anthropic_client to None so anthropic returns (None, None), letting the chain reach the custom endpoint as intended. Also set HERMES_INFERENCE_PROVIDER=custom so _resolve_custom_runtime() mirrors the env-driven setup without falling through to unrelated provider paths.
_model_flow_custom() writes model.provider and model.base_url to disk via its own fresh load_config() + save_config() cycle, but the outer dict passed in by run_setup_wizard() is never updated in-place. The final save_config(config) at the bottom of run_setup_wizard() then overwrites the file with the stale outer dict, silently stripping model.provider and model.base_url from config.yaml. Net effect: after 'hermes setup' with a custom endpoint, .env has the right OPENAI_BASE_URL / OPENAI_API_KEY but config.yaml has no provider or base_url — the user must run 'hermes model' again to fix it. Fix: after _model_flow_custom() returns, reload the on-disk state back into the outer config dict so the subsequent save_config(config) is a no-op rather than a destructive overwrite. Fixes NousResearch#3415. Tests: test_custom_setup_wizard_persists_provider_in_config
Contributor
|
Both issues in this PR are now resolved on main:
Thanks for the thorough analysis of both issues, @Mibayy! |
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.
Summary
Fixes #3410.
Two separate bugs that both affect custom OpenAI-compatible endpoint users.
Fix 1 —
auxiliary_client: mirror active runtime in_resolve_custom_runtimeRoot cause
_resolve_custom_runtime()hardcodedrequested="custom"when callingresolve_runtime_provider(). The problem:_get_named_custom_provider()explicitly returns
Nonewhenrequested_norm == "custom"— it only matchesnamed entries like
custom:local. So named custom providers saved inconfig.yamlwere silently bypassed.The auxiliary path then fell through to env-var resolution
(
OPENAI_BASE_URL/OPENAI_API_KEY), which can carry different credentialsor nothing at all — even though the main agent was already running successfully
against the named provider.
Fix
If the active provider is not a custom endpoint (e.g.
nous,openrouter),fall back to
requested="custom"so env-drivenOPENAI_BASE_URLsetups keep working.Also adds
DEBUG-level logging of the credential source selected for auxiliaryresolution.
Fix 2 —
setup: reload config after_model_flow_customto prevent clobberRoot cause
_model_flow_custom()writesmodel.providerandmodel.base_urlto disk viaits own independent
load_config()+save_config()cycle — it does notmutate the outer
configdict thatrun_setup_wizard()holds.After
_model_flow_customreturns,run_setup_wizard()callssave_config(config)with the stale outer dict (no
provider, nobase_url), silently overwritingthe correct values.
Net effect:
.envis right,config.yamlis wrong → the user must runhermes modelagain to recover, and vision / auxiliary tooling also fails.Fix
After
_model_flow_custom()returns, reload the on-disk state back into theouter
configdict so the subsequentsave_config(config)is a no-op:Changes
agent/auxiliary_client.py—_resolve_custom_runtime(): useresolve_requested_provider()firsthermes_cli/setup.py—run_setup_wizard(): reload config after custom flowtests/agent/test_auxiliary_client.py— 5 new tests + isolation fixtests/hermes_cli/test_setup_model_provider.py— regression test for config clobberTests