Problem

Users using non-OpenAI embedding providers (Ollama/nomic-embed-text, Google/Gemini, HuggingFace, etc.) hit Bad Request errors when using Qdrant because the vector store was always created with a hardcoded default dimension of 1536 (OpenAI's dimension), regardless of the actual embedding model's output dimension.

This caused three related issues:

• Qdrant collection created with wrong dimensions when using Ollama embedder (nomic-embed-text) #4212 — Ollama + nomic-embed-text (768 dims) → Qdrant collection created with 1536 dims → Bad Request on insert
• Bug: Qdrant collection created with wrong vector dimension when using Ollama embeddings #4173 — Same root cause with different embedding providers
• Mem0 local qdrant error #4056 — Race condition during Qdrant collection creation + memory_migrations collection using wrong dimension

Solution

1. Probe-based dimension auto-detection

When no explicit dimension is provided, the Memory class now embeds a short probe string ("dimension probe") at initialization time and reads the resulting vector length to determine the correct dimension. This happens before the vector store is created.

Dimension resolution order:

1. Explicit vectorStore.config.dimension (user override)
2. embedder.config.embeddingDims (embedder config)
3. Auto-detected via probe embedding (new fallback)

2. Deferred vector store creation

The vector store is no longer created in the Memory constructor. Instead, it's created in an async _autoInitialize() method after the dimension is known. All public Memory methods (add, search, getAll, etc.) await initialization before proceeding via a lazy init gate (_ensureInitialized()).

3. Atomic Qdrant collection creation

Replaced the check-then-create pattern (TOCTOU race) with create-and-catch-409:

try {
  await this.client.createCollection(name, { vectors: { size, distance: "Cosine" } });
} catch (error) {
  if (error?.status === 409) {
    // Collection already exists — verify dimension matches
  } else {
    throw error;
  }
}

4. Idempotent init guards for all vector stores

Every vector store with async initialization (Qdrant, Redis, Supabase, AzureAISearch, Vectorize) now uses a _initPromise singleton guard. This prevents double-initialization when Memory explicitly calls await vectorStore.initialize() after the constructor already fired it:

private _initPromise?: Promise<void>;

async initialize(): Promise<void> {
  if (!this._initPromise) {
    this._initPromise = this._doInitialize();
  }
  return this._initPromise;
}

Without this guard:

• Redis: Double connect() → "Socket already opened", plus dropIndex/createIndex destroys the index the first call just built
• Qdrant: Double createCollection → 409 Conflict crash
• Vectorize: Double indexes.create() → Cloudflare API error
• Supabase/AzureAISearch: Redundant network calls and potential transient failures

5. Google embedder fix

Fixed hardcoded outputDimensionality: 768 in google.ts — now uses this.embeddingDims from config.

Files Changed

Testing

Unit Tests (61 tests)

• dimension-autodetect.test.ts (22 tests) — ConfigManager dimension resolution, MemoryVectorStore backward compat, Memory auto-initialization, error propagation
• config-manager.test.ts (5 tests) — ConfigManager dimension priority chain
• vector-stores-compat.test.ts (34 tests) — Backward compatibility for all 7 vector store implementations (MemoryVectorStore, Qdrant, Redis, Supabase, AzureAISearch, Vectorize, Langchain) with mocked clients

End-to-End Tests (21 tests, against real instances)

• qdrant-e2e.test.ts (8 tests) — Against real Qdrant v1.13.0:
  • Reproduces the exact Bad Request error from Qdrant collection created with wrong dimensions when using Ollama embedder (nomic-embed-text) #4212/Bug: Qdrant collection created with wrong vector dimension when using Ollama embeddings #4173
  • Verifies 768-dim CRUD works after fix
  • Memory auto-detects dims via probe (full integration)
  • Explicit dimension and embeddingDims skip probe (backward compat)
  • Concurrent ensureCollection race condition (5 parallel instances)
  • getUserId/setUserId after concurrent init
  • memory_migrations uses dim=1 independently of main collection
• redis-e2e.test.ts (13 tests) — Against real Redis Stack:
  • Idempotent init (multiple concurrent calls)
  • Full CRUD: insert, search, get, update, delete
  • List with filters
  • getUserId/setUserId roundtrip
  • Correct dimension propagation from config

Total: 82 tests, all passing

Checklist

• Fixes Qdrant collection created with wrong dimensions when using Ollama embedder (nomic-embed-text) #4212, Bug: Qdrant collection created with wrong vector dimension when using Ollama embeddings #4173, Mem0 local qdrant error #4056
• Backward compatible — explicit dimension config still works, no probe triggered
• All existing tests pass
• New unit tests for dimension resolution and backward compatibility
• End-to-end tests against real Qdrant and Redis Stack instances
• No breaking changes to public API
• All vector store implementations verified (Qdrant, Redis, Supabase, AzureAISearch, Vectorize, Langchain, MemoryVectorStore)
• Race conditions handled (concurrent init, TOCTOU collection creation)
• Error messages are helpful (probe failure tells user to set dimension explicitly)