mem0ai/mem0 · error · Error

Delete failed for document ${vectorId}: ${result.errorMessag

Error message

Delete failed for document ${vectorId}: ${result.errorMessage}

What it means

delete(vectorId) calls deleteDocuments([{ id: vectorId }]) and then checks each per-document result; if result.succeeded is false it throws with the document id and Azure's errorMessage. Azure AI Search reports per-document outcomes even when the HTTP call succeeds, so a failed delete (e.g. wrong key type or index unavailable) surfaces here rather than as a rejected promise.

Source

Thrown at mem0-ts/src/oss/src/vector_stores/azure_ai_search.ts:459

        payload,
      });
    }

    return results;
  }

  /**
   * Delete a vector by ID
   */
  async delete(vectorId: string): Promise<void> {
    await this.initialize();
    const response = await this.searchClient.deleteDocuments([
      { id: vectorId },
    ]);

    for (const result of response.results) {
      if (!result.succeeded) {
        throw new Error(
          `Delete failed for document ${vectorId}: ${result.errorMessage}`,
        );
      }
    }

    console.log(
      `Deleted document with ID '${vectorId}' from index '${this.indexName}'.`,
    );
  }

  /**
   * Update a vector and its payload
   */
  async update(
    vectorId: string,
    vector: number[],
    payload: Record<string, any>,
  ): Promise<void> {

View on GitHub (pinned to 001c235229)

Solutions

Inspect errorMessage in the thrown message: for throttling, retry after a backoff.
Confirm the id being deleted is exactly the one returned at insert time (no trimming/sanitizing differences).
Verify the target index exists and is not in the middle of a rebuild.

Defensive patterns

Strategy: retry

Try / catch

try { await memory.delete(id) }
catch (e) {
  if (e instanceof Error && /Delete failed for document/.test(e.message)) {
    if (/throttl|503|busy/i.test(e.message)) { await sleep(2000); await memory.delete(id); }
    else throw e;
  } else throw e;
}

Prevention

Delete using ids exactly as returned by search/add results.
Treat per-document delete failures as retryable for transient messages; non-transient ones usually mean the index schema/state changed.
Avoid interleaving index rebuilds with delete traffic.

When it happens

Trigger: memory.delete(id) on Azure AI Search when the index is being rebuilt/recreated; the id does not conform to the index key (e.g. characters Azure rejects for a key field); throttling during a delete batch.

Common situations: Deleting memories right after index recreation; ids sanitized differently than at insert time; transient 503s on a free-tier search service.

Related errors

AI-assisted analysis of mem0ai/mem0@001c235229 (2026-08-15). Data as JSON: /api/errors/cf41a45cef810233. Report an issue: GitHub.