fix: misleading error when auxiliary provider credential pool is exhausted#21428
Open
li0near wants to merge 1 commit into
Open
fix: misleading error when auxiliary provider credential pool is exhausted#21428li0near wants to merge 1 commit into
li0near wants to merge 1 commit into
Conversation
… exhausted When a provider's credential pool has all entries marked exhausted (e.g. from a prior 401), the auxiliary client returns None and the downstream error message incorrectly tells the user 'no API key was found' — pointing them toward missing env vars when the real issue is stale pool state. This change: - Adds a logger.warning in _try_anthropic() when pool exists but all entries are exhausted, mentioning `hermes auth reset` as the fix. - In both call_llm() and async_call_llm(), checks for exhausted pool before raising the generic 'no API key' RuntimeError, and raises a more accurate message pointing to `hermes auth reset <provider>`. Fixes the case where a one-time auth failure (e.g. proxy rejecting a key on first run) permanently poisons the credential pool and all subsequent auxiliary calls (compression, title generation, vision, etc.) fail with misleading error messages.
076545f to
c53ba87
Compare
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
2 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.
Problem
When a provider's credential pool has all entries marked exhausted (e.g. from a prior 401 against a proxy), auxiliary tasks (compression, title generation, vision, etc.) fail with:
This is misleading — the API key is configured and loads correctly, but the credential pool has a stale exhaustion marker that blocks the client from ever attempting to use it. The user has no way to diagnose this without inspecting
auth.jsonmanually.Root Cause
_try_anthropic()returns(None, None)silently when_select_pool_entry()returns(True, None)(pool exists, all entries exhausted). The downstreamcall_llm()/async_call_llm()then raises a generic "no API key" error that points to the wrong fix.Fix
_try_anthropic(): Addlogger.warning()when pool exists but all entries are exhausted, mentioninghermes auth reset anthropicas the resolution.call_llm()andasync_call_llm(): Before raising the generic "no API key" RuntimeError, check if the provider has an exhausted pool. If so, raise a more accurate error pointing tohermes auth reset <provider>.After
Reproduction
auxiliary.title_generation.provider: anthropicwith a custom proxyauth.jsonRelated: #10476 (silent provider fallback), but distinct — this is about the error message accuracy, not fallback notification.