dotnet/efcore · error · NotSupportedException
The Cosmos database does not support 'CanConnect' or 'CanCon
Error message
The Cosmos database does not support 'CanConnect' or 'CanConnectAsync'.
What it means
The Cosmos DB provider does not implement health-check style connectivity verification. CanConnectAsync (CosmosDatabaseCreator.cs:277-278) unconditionally throws NotSupportedException because Cosmos does not expose a lightweight 'can I reach the database?' probe that EF Core can call without side effects. The sync CanConnect variant throws SyncNotSupported instead (see error 131).
Source
Thrown at src/EFCore.Cosmos/Storage/Internal/CosmosDatabaseCreator.cs:278
}
/// <summary>
/// This is an internal API that supports the Entity Framework Core infrastructure and not subject to
/// the same compatibility standards as public APIs. It may be changed or removed without notice in
/// any release. You should only use it directly in your code with extreme caution and knowing that
/// doing so can result in application failures when updating to a new Entity Framework Core release.
/// </summary>
public virtual Task<bool> EnsureDeletedAsync(CancellationToken cancellationToken = default)
=> _cosmosClient.DeleteDatabaseAsync(cancellationToken);
/// <summary>
/// This is an internal API that supports the Entity Framework Core infrastructure and not subject to
/// the same compatibility standards as public APIs. It may be changed or removed without notice in
/// any release. You should only use it directly in your code with extreme caution and knowing that
/// doing so can result in application failures when updating to a new Entity Framework Core release.
/// </summary>
public virtual Task<bool> CanConnectAsync(CancellationToken cancellationToken = default)
=> throw new NotSupportedException(CosmosStrings.CanConnectNotSupported);
/// <summary>
/// Returns the store names of the properties that is used to store the partition keys.
/// </summary>
/// <remarks>
/// This is an internal API that supports the Entity Framework Core infrastructure and not subject to
/// the same compatibility standards as public APIs. It may be changed or removed without notice in
/// any release. You should only use it directly in your code with extreme caution and knowing that
/// doing so can result in application failures when updating to a new Entity Framework Core release.
/// </remarks>
/// <param name="entityType">The entity type to get the partition key property names for.</param>
/// <returns>The names of the partition key property.</returns>
private static IReadOnlyList<string> GetPartitionKeyStoreNames(IEntityType entityType)
{
var properties = entityType.GetPartitionKeyProperties();
return properties.Any()
? properties.Select(p => p.GetJsonPropertyName()).ToList()
: [CosmosClientWrapper.DefaultPartitionKey];View on GitHub (pinned to dbf9771522)
Solutions
- Do not use EF Core's CanConnect for Cosmos health checks. Instead, use the Cosmos SDK's Microsoft.Azure.Cosmos.Database.ReadAsync or a custom IHealthCheck that pings the Cosmos client.
- Exclude Cosmos-backed DbContexts from .AddDbContextCheck and register a dedicated Cosmos health check (e.g., fromAspNetCore.Diagnostics.HealthChecks or a custom implementation).
- If you must use a connectivity probe, wrap a raw Cosmos SDK call (client.GetDatabase(name).ReadStreamAsync()) in a try/catch.
Example fix
// before
services.AddHealthChecks().AddDbContextCheck<CosmosDbContext>();
// after
services.AddHealthChecks().AddAzureCosmosDB(
cosmosClientFactory: sp => sp.GetRequiredService<CosmosClient>(),
databaseName: "MyDb"); Defensive patterns
Strategy: fallback
Validate before calling
// Do not call CanConnect on Cosmos. Use a Cosmos SDK probe instead.
static async Task<bool> CanConnectCosmosAsync(CosmosClient client, string dbName, CancellationToken ct = default)
{
try { await client.GetDatabase(dbName).ReadAsync(cancellationToken: ct); return true; }
catch (CosmosException) { return false; }
} Try / catch
// If third-party code calls CanConnectAsync, catch NotSupportedException and fall back to a Cosmos SDK probe.
try { await context.Database.CanConnectAsync(); }
catch (NotSupportedException) { /* use Cosmos SDK health check instead */ } Prevention
- Never register Cosmos DbContexts with AddDbContextCheck.
- Use a dedicated Cosmos health check (e.g., AddAzureCosmosDB) for health endpoints.
- Document in your team that CanConnect is unsupported for Cosmos.
When it happens
Trigger: Calling context.Database.CanConnectAsync() or context.GetDatabaseCreator().CanConnectAsync() on a DbContext configured with UseCosmos. Also triggered by ASP.NET Core health check infrastructure that invokes CanConnect when EFCore is registered as a health check.
Common situations: Adding .AddDbContextCheck<MyContext>() to an ASP.NET Core health check pipeline with a Cosmos-backed context. Calling CanConnect in startup to verify connectivity. Using a shared health-check library that probes all registered DbContexts.
Related errors
- The type '{givenType}' cannot be mapped as a dictionary beca
- The value '{value}' provided for argument '{argumentName}' m
- Cosmos-specific methods can only be used when the context is
- The '{methodName}' method is not supported because the query
- The requested configuration is not stored in the read-optimi
AI-assisted analysis of dotnet/efcore@dbf9771522 (2026-08-06).
Data as JSON: /api/errors/ee1268be74e07a3b.
Report an issue: GitHub.