doctor: probe Groq + Mistral in API Connectivity section (#32)#33
Merged
Conversation
Auditing other surfaces for diagnostic-loudness gaps. Found the same shape I closed in `hermes status` via #10/#11: doctor's _build_apikey_providers_list() static list (drives the parallel HTTP /models reachability probes) was missing Groq + Mistral despite both being first-class providers (config.py registers MISTRAL_API_KEY; doctor.py:99 references GROQ_API_KEY for STT fallback; status.py post-#11 lists them in API Keys). Result: operators with valid GROQ_API_KEY / MISTRAL_API_KEY got ✓ in API Keys but never a connectivity-validated ✓ in API Connectivity — so a malformed/expired key looked identical to a working one until the first actual request 401'd. Add both rows to _static. Both use the generic Bearer-auth /v1/models endpoint that _probe_apikey_provider already handles — no custom-header logic required. Closes #32.
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
1 participant
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
Closes #32. Auditing other surfaces for diagnostic-loudness gaps and found the same shape I closed in
hermes statusvia #10/#11, but in a different surface:_build_apikey_providers_list()inhermes_cli/doctor.py(drives the parallel HTTP/modelsreachability probes in the API Connectivity section) was missing Groq + Mistral.Why this matters
Both providers are already first-class elsewhere:
hermes_cli/config.py:2325registersMISTRAL_API_KEY.hermes_cli/doctor.py:99referencesGROQ_API_KEY(STT fallback).hermes_cli/status.py:127post-status: add Groq + Mistral rows, hint when $HOME/.env present #11 lists them in the API Keys section.But the doctor probe loop never probed them. So an operator with
GROQ_API_KEY=garbageor an expiredMISTRAL_API_KEYgot ✓ in API Keys and silence in API Connectivity — exactly the false-positive pattern this section was designed to catch.Fix
Two new rows in the
_staticlist, both using the generic Bearer-auth/v1/modelsendpoint that_probe_apikey_provideralready handles unchanged:No conflict with
ProviderProfilededup — neither Groq nor Mistral has a registered profile inplugins/model-providers/, so the canonical-name set doesn't shadow them.Test plan
tests/hermes_cli/test_doctor.py::TestApiKeyProvidersList:GROQ_API_KEYenv var +/modelsURL +GROQ_BASE_URLoverride_build_apikey_providers_list()merges static + ProviderProfile; duplicates would break the parallel probe loop's name keying)pytest tests/hermes_cli/test_doctor.py→ 64 passed (61 existing + 3 new)Filed by hermes-maintainer (PowerCreek).