bug(claude): validate_connection fails on Azure AI Foundry -- models.list() not supported

[nskun]

Summary:

ClaudeProvider.validate_connection() unconditionally calls client.models.list() to verify connectivity.
Azure AI Foundry's Anthropic endpoint does not support this API, causing validate_connection() to always return False.
This blocks workflow execution at startup.

Environment

Conductor v0.1.31
Anthropic Python SDK(latest)
Endpoint: Azure AI Foundry(https://.services.ai.azure.com/anthropic)
Authentication: API key via ANTHROPIC_API_KEY

Steps to Reproduce

1. Configure Conductor to use Azure AI Foundry's Anthropic endpoint:

export ANTHROPIC_BASE_URL=https://<resource>.services.ai.azure.com/anthropic
export ANTHROPIC_API_KEY=<key>

2.Run any workflow:

conductor run workflow.yaml

3.Observe: startup fails with connection validation error.

Root Cause

In claude.py L379, validate_connection() calls

async def validate_connection(self) -> bool:
    # ...
    try:
        await self._client.models.list() # <- fails on Azure AI Foundry
        await self._log_available_models()
        return True
    except Exception as e:
        logger.error(f"Connection validation failed: {e}")
        return False # <- always reached

Azure AI Foundry's Anthropic endpoint does not implement the /v1/models API.
The models.list() call raises an exception(404 or similar), and validate_connection() returns False.

The actual inference endpoint(/v1/messages) works fine -- only the model listing is unsupported.

[jrob5756]

Confirmed, and it's broader than Foundry: any Anthropic-compatible endpoint that doesn't implement /v1/models hits this.

I reproduced it against a stub gateway that 404s GET /v1/models and serves POST /v1/messages normally:

validate_connection() -> False
messages.create() -> 'pong'   (inference works)

conductor run then exits 1 with ProviderError: Failed to connect to claude provider, suggesting you check your credentials and network connection, neither of which was the problem.

Your root cause analysis is correct. Two things make this a defect rather than a misconfiguration.

First, validate_connection() is a hard startup gate. registry.py calls create_provider(..., validate=True) and factory.py turns a False into a fatal ProviderError.

Second, every other models.list() call site in claude.py already tolerates failure. _log_available_models() logs a warning, get_max_prompt_tokens() returns None under the comment "context-window metadata must never block workflow execution", and list_models() returns None. validate_connection() is the only one that hard-fails. The other providers agree with that posture: hermes doesn't verify endpoint reachability at all, and claude-agent-sdk deliberately skips the API round trip.

It also contradicts our own docs. docs/providers/claude.md documents LiteLLM, Databricks AI Gateway and other enterprise endpoints as supported through base_url, and /v1/models isn't part of the Messages contract those implement. On the Foundry side, Microsoft documents Messages and Token counting as the API surface for /anthropic. /v1/models doesn't appear anywhere in those docs, and Microsoft's own Claude Code integration hardcodes deployment names rather than discovering them.

The approach we're planning: narrow the blanket except Exception in validate_connection() so a 404 (anthropic.NotFoundError) is read as "endpoint reachable, model listing unavailable", which logs a warning and returns True. Auth failures (401/403), connection errors and everything else stay fatal, so a bad key is still caught at startup against the standard Anthropic endpoint. Model discovery then degrades on its own, since _log_available_models() already swallows AnthropicError. You'd lose the cache seeding and the model-name warning on Foundry, which is no real loss there given Foundry addresses deployment names rather than model IDs.

Same shape as #193, which fixed the equivalent problem on the Copilot provider.

One trade-off to flag: a genuinely wrong base_url (a duplicated /v1, say) 404s on every route, so that case will now pass startup and fail at first execution instead. That matches how the other providers already behave.

Thanks for the report, the file, line and root cause all checked out.

[jrob5756]

Starting to take a look at this.

[nskun]

Thanks for the quick fix! I’ve confirmed that it works correctly now.