Skip to content

fix: check user-defined providers before builtin alias guard#16342

Closed
dkwallace wants to merge 1 commit into
NousResearch:mainfrom
dkwallace:fix/user-providers-priority-over-builtin-aliases
Closed

fix: check user-defined providers before builtin alias guard#16342
dkwallace wants to merge 1 commit into
NousResearch:mainfrom
dkwallace:fix/user-providers-priority-over-builtin-aliases

Conversation

@dkwallace

Copy link
Copy Markdown

Summary

_get_named_custom_provider was checking the builtin provider alias guard *before* checking user-defined providers from the providers: dict. This caused user-defined providers whose names happen to match a built-in alias (e.g. llama-cpp) to be silently rejected as "not a custom provider" — the user's config entry was never examined.

Root Cause

The guard at the top of the function called auth_mod.resolve_provider(requested_norm) and returned None if the name matched a known built-in alias. This happened before any user-defined provider lookup.

Fix

Moved the builtin guard to the end of _get_named_custom_provider, after both the providers: dict and custom_providers: list are checked. User-defined providers now take priority over built-in aliases, which is the correct behavior — user configuration should always win.

Test Plan

  • Verified locally: _get_named_custom_provider("llama-cpp") now returns the user's providers: entry instead of None
  • Existing tests should continue to pass (logic is reordered, not removed)

Closes # (no issue filed)

_get_named_custom_provider had the builtin provider guard at the top
of the function, before the user-defined `providers:` dict was checked.
This meant a user-defined provider whose name happened to match a
built-in alias (e.g. "llama-cpp") was rejected as "not a custom
provider" before the user's config entry was even examined.

Moves the builtin guard to the end of the function, so user-defined
providers in both `providers:` (dict) and `custom_providers:` (list)
formats are checked first. Only if no user-defined match is found
does the function check whether the name is a known built-in.
@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/cli CLI entry point, hermes_cli/, setup wizard area/config Config system, migrations, profiles labels Apr 27, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Related to #13134 — same root cause: builtin alias guard checked before user-defined providers dict.

@teknium1

Copy link
Copy Markdown
Contributor

Closing as superseded by #18185.

Triage notes (high confidence):
Main's _get_named_custom_provider (hermes_cli/runtime_provider.py:485-502) now defers to built-in only when the raw name equals the canonical provider (not when it is an alias), addressing the same shadowing concern via a different approach. PR #18185 'fix(fallback): let custom_providers shadow built-in aliases' merged 2026-05-01.

Thanks for the contribution — the underlying problem this PR addresses has been resolved by the linked PR on current main. If you believe this was closed in error, please comment and we'll reopen.

(Bulk-closed during a CLI PR triage sweep.)

@teknium1 teknium1 closed this May 24, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/config Config system, migrations, profiles comp/cli CLI entry point, hermes_cli/, setup wizard P2 Medium — degraded but workaround exists type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants