microsoft/semantic-kernel · error · VectorStoreOperationException

Failed to get database proxy for '{id}'.

Error message

Failed to get database proxy for '{id}'.

What it means

_get_database_proxy wraps its body in try/except and re-wraps any unhandled exception as VectorStoreOperationException. NOTE: the message references '{id}', a variable that is not defined in scope (likely a copy-paste bug; intended is self.database_name). The chained __cause__ holds the real error.

Source

Thrown at python/semantic_kernel/connectors/azure_cosmos_db.py:644

            return True
        except CosmosResourceNotFoundError:
            return False
        except Exception as e:
            raise VectorStoreOperationException(
                f"Failed to check if database '{self.database_name}' exists, with message {e}"
            ) from e

    async def _get_database_proxy(self, **kwargs) -> DatabaseProxy:
        """Gets the database proxy."""
        try:
            if await self._does_database_exist():
                return self.cosmos_client.get_database_client(self.database_name)

            if self.create_database:
                return await self.cosmos_client.create_database(self.database_name, **kwargs)
            raise VectorStoreOperationException(f"Database '{self.database_name}' does not exist.")
        except Exception as e:
            raise VectorStoreOperationException(f"Failed to get database proxy for '{id}'.") from e

    async def _get_container_proxy(self, container_name: str, **kwargs) -> ContainerProxy:
        """Gets the container proxy."""
        try:
            database_proxy = await self._get_database_proxy(**kwargs)
            return database_proxy.get_container_client(container_name)
        except Exception as e:
            raise VectorStoreOperationException(f"Failed to get container proxy for '{container_name}'.") from e


# region: NoSQL Collection


@release_candidate
class CosmosNoSqlCollection(
    CosmosNoSqlBase,
    VectorStoreCollection[TNoSQLKey, TModel],
    VectorSearch[TNoSQLKey, TModel],

View on GitHub (pinned to c028a0c7dc)

Solutions

  1. Inspect exc.__cause__ to identify the real failure (network, auth, throttling, etc.).
  2. File/fix the bug: replace '{id}' with '{self.database_name}' in the message for clarity.
  3. Address the underlying cause (credentials, connectivity, provisioning, RU).

Example fix

// before
raise VectorStoreOperationException(f"Failed to get database proxy for '{id}'.") from e
// after
raise VectorStoreOperationException(f"Failed to get database proxy for '{self.database_name}'.") from e
Defensive patterns

Strategy: try-catch

Try / catch

try:
    proxy = await store._get_database_proxy()
except VectorStoreOperationException as e:
    cause = e.__cause__  # real underlying error
    # address based on cause type

Prevention

When it happens

Trigger: Raised in _get_database_proxy's except block when an exception escapes the existence check and create path. Because the message uses an undefined 'id', in practice this either NameErrors or surfaces a confusing message; the underlying cause is what matters.

Common situations: This is effectively a fallback catch for _does_database_exist or create_database failures not already handled. In practice you'll usually see errors 1252/1253 first. If you see this one, inspect __cause__.

Related errors


AI-assisted analysis of microsoft/semantic-kernel@c028a0c7dc (2026-08-13). Data as JSON: /api/errors/c160ce0aa6c3123b. Report an issue: GitHub.