Fix auxiliary Vertex provider resolution - #701
Open
hashbender wants to merge 1 commit into
Open
Conversation
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.
Fixes NousResearch#56810.
Summary
hermes_cli.auth.PROVIDER_REGISTRYdoes not contain non-API-key providers such as Vertex.google-vertex,vertex-ai,gcp-vertex,vertexai) to auxiliary provider normalization.VERTEX_API_KEYexplicit-provider error with Vertex OAuth2/ADC guidance for both sync and async auxiliary calls.Why this is broader than the message-only fixes
NousResearch#56842 and NousResearch#56843 fix the misleading error text. This PR also fixes the resolution path that led to the error in the first place:
resolve_provider_client("google-vertex", ...)normalized tovertex, then looked only inhermes_cli.auth.PROVIDER_REGISTRY.vertexis intentionally absent from that registry because it uses OAuth2/ADC, not static API-key env vars.auth_type == "vertex"branch unreachable for auxiliary tasks, so valid Vertex credentials could still be ignored.ProviderProfilemetadata for providers missing fromPROVIDER_REGISTRY, which lets Vertex reach the existing Vertex OAuth2 client path while preserving the old API-key path for ordinary providers.Related context: NousResearch#56688 handles Vertex registry/overlay wiring from another angle. This PR keeps the auxiliary fix local to
agent/auxiliary_client.pyand does not require making Vertex look like an API-key provider.Tests
scripts/run_tests.sh tests/agent/test_auxiliary_client.py tests/hermes_cli/test_vertex_provider.py tests/agent/test_vertex_adapter.py tests/agent/test_bedrock_integration.py tests/agent/test_auxiliary_client_resolve_dedup.py— 371 passed..venv/bin/ruff check agent/auxiliary_client.py tests/agent/test_auxiliary_client.py— passed.git diff --check— passed.scripts/run_tests.shafter installing.[all,dev]: 1818 files, 37336 tests passed, 40 failed, plustests/run_agent/test_run_agent.pyhit the 300s per-file timeout. Observed failures were outside this change area: Anthropic keychain mocked-subprocess tests, macOS systemd/user D-Bus assumptions, macOS/tmpvs/private/tmppath normalization, SSRF-guarded test domains resolving to private/internal addresses, browser/cloud routing environment assumptions, and a long run-agent file timeout. Vertex/auxiliary/provider-profile related tests passed in the full run.Review
Mirror-of: NousResearch#56861
NousResearch#56861