microsoft/semantic-kernel · warning · ServiceResponseException

Failed to remove all keys, {result.delete_count} removed out

Error message

Failed to remove all keys, {result.delete_count} removed out of {len(keys)}

What it means

Raised as a ServiceResponseException in MilvusMemoryStore.remove_batch when result.delete_count does not equal len(keys), meaning some keys were not deleted (typically because they did not exist in the collection). This is a partial-success signal: the delete operation completed but not all requested keys matched.

Source

Thrown at python/semantic_kernel/connectors/memory_stores/milvus/milvus_memory_store.py:380

        Raises:
            Exception: Collection doesnt exist.
            e: Failure to remove key.
        """
        if collection_name not in utility.list_collections():
            logger.debug(f"Collection {collection_name} does not exist, cannot remove.")
            raise ServiceResourceNotFoundError(f"Collection {collection_name} does not exist, cannot remove.")
        try:
            self.collections[collection_name].load()
            result = self.collections[collection_name].delete(
                expr=f"{SEARCH_FIELD_ID} in {keys}",
            )
            self.collections[collection_name].flush()
        except Exception as e:
            logger.debug(f"Remove failed due to: {e}")
            raise ServiceResponseException(f"Remove failed due to: {e}") from e
        if result.delete_count != len(keys):
            logger.debug(f"Failed to remove all keys, {result.delete_count} removed out of {len(keys)}")
            raise ServiceResponseException(
                f"Failed to remove all keys, {result.delete_count} removed out of {len(keys)}"
            )

    async def get_nearest_matches(
        self,
        collection_name: str,
        embedding: ndarray,
        limit: int,
        min_relevance_score: float = 0.0,
        with_embeddings: bool = False,
    ) -> list[tuple[MemoryRecord, float]]:
        """Find the nearest `limit` matches for an embedding.

        Args:
            collection_name (str): The collection to search.
            embedding (ndarray): The embedding to search.
            limit (int): The total results to display.
            min_relevance_score (float, optional): Minimum distance to include. Defaults to None.

View on GitHub (pinned to c028a0c7dc)

Solutions

If partial deletion is acceptable, catch ServiceResponseException and log which keys may remain.
Pre-filter keys to those known to exist (via a query) before calling remove_batch.
Treat remove as idempotent: ignore this error if the end state (keys absent) is the goal.
Log result.delete_count vs len(keys) for diagnostics.

Example fix

// before
await store.remove_batch('docs', keys)  # ServiceResponseException: Failed to remove all keys...
// after
try:
    await store.remove_batch('docs', keys)
except ServiceResponseException as e:
    if 'Failed to remove all keys' in str(e):
        logging.info('Partial remove (some keys already absent): %s', e)
    else:
        raise

Defensive patterns

Strategy: try-catch

Validate before calling

# Pre-filter keys to those that exist before removing
existing = await store.get_batch('docs', keys, with_embeddings=False)
existing_ids = {r._id for r in existing}
keys_to_remove = [k for k in keys if k in existing_ids]
if keys_to_remove:
    await store.remove_batch('docs', keys_to_remove)

Try / catch

from semantic_kernel.exceptions import ServiceResponseException

try:
    await store.remove_batch('docs', keys)
except ServiceResponseException as e:
    if 'Failed to remove all keys' in str(e):
        logging.info('Partial remove — some keys already absent: %s', e)
    else:
        raise

Prevention

Treat remove_batch as idempotent: some missing keys is often acceptable.
Pre-filter keys to existing records when exact counts matter.
Log delete_count vs len(keys) for diagnostics.
Catch the partial-failure message distinctly from hard failures.

When it happens

Trigger: Calling remove_batch with a keys list where some keys are absent from the collection. Milvus returns a delete_count lower than the number of keys submitted, so the mismatch check triggers even though the operation itself succeeded.

Common situations: Idempotent cleanup passing already-deleted or never-existing keys. Stale key references from a different data run. Bulk deletion where a subset of records were removed by a prior operation.

Related errors

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