Uh oh!
There was an error while loading. Please reload this page.
fix(providers): treat non-credential HTTP failures from Claude models.list() as inconclusive - #457
Merged
Jason Robert (jrob5756) merged 3 commits intoAug 18, 2026
Conversation
….list() as inconclusive Azure AI Foundry and some LiteLLM/Databricks gateways answer models.list() with a 404 while /v1/messages works fine, causing validate_connection() to fail startup even though the endpoint is usable. Classify a models.list() failure via _connection_probe_verdict: an unreachable host, rejected credentials (401/403), or a non-HTTP error still fails startup, but any other HTTP status is now treated as inconclusive so the workflow proceeds and credentials are verified at the first agent execution instead.
… of hiding them Addresses PR #457 review findings: - claude.py: narrow the duck-typed status_code to int (excluding bool) before the 401/403 check, so a stringified or Mock-shaped status no longer fails open and boots a workflow with rejected credentials. - claude.py: record an inconclusive models.list() probe on the instance (_connection_probe_note) and short-circuit get_max_prompt_tokens()/ list_models() once model listing is known unavailable (_model_listing_unavailable), instead of re-attempting a guaranteed-failing round-trip on every agent step. - diagnostics.py: add ProviderDiagnostic.connection_note, populate it from the new instance attribute, and gate the doctor --models list_models() call on a verified (not merely truthy) connection. - doctor.py + fleet/tui/screens/providers.py: render a distinct "unverified" state instead of a false "connected" checkmark when the probe never actually verified the endpoint. - docs/providers/claude.md: correct the probe attribution — it's `conductor run` (via provider construction) and `conductor doctor --check`/`--models` that probe the endpoint; `conductor validate` never constructs a provider or contacts the network. - tests: add coverage for a stringified and a directly-attached duck-typed status code, both asserting the credential-rejection path still fails closed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Jason Robert (jrob5756)
marked this pull request as ready for review
August 17, 2026 22:55
…ection-azure-foundry # Conflicts: # CHANGELOG.md
Uh oh!
There was an error while loading. Please reload this page.
Jason Robert (jrob5756)
deleted the
fix/455-validate-connection-azure-foundry
branch
August 18, 2026 16:14
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 freeto 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
Azure AI Foundry and some LiteLLM/Databricks gateways answer
models.list()with a 404 while/v1/messagesworks fine, causingvalidate_connection()to fail startup even though the endpoint is usable. This treats a non-credential, non-connection HTTP failure from that probe as inconclusive instead of fatal: the workflow proceeds and credentials are verified at the first agent execution.Closes#455