Context: We run surreal-memory as the production memory engine for our agent swarm (Uruboros), via both the stdio MCP server and the CLI. Full open cards.
Problem: smem_remember over the MCP interface reliably times out at the client's 30s tool-call cap (Claude Code / Claude Desktop) because the embedding is computed synchronously inside the write path (our embedding provider is a proxied Gemini endpoint). The identical write via the CLI (smem remember --stdin) succeeds — no 30s cap. Reproduced repeatedly 2026-07-08/09.
Impact: A memory tool whose whole purpose is to prevent cross-session loss will silently drop writes on any MCP client with a bounded tool timeout: the agent "remembers", gets a timeout, and cannot tell whether the write landed. This is the exact failure mode the tool exists to prevent, and it affects any MCP host with a per-call timeout, not just our setup.
Suspected root cause: the embedding provider is awaited synchronously in remember before returning; a slow/remote provider (proxy, rate limit, cold start) pushes total latency past 30s.
Proposed fix (open to discussion):
- Ack-first, embed-async (preferred): persist the neuron immediately (without
embedding_vec), return success, compute the embedding in a background task, and backfill embedding_vec + reindex HNSW when ready. Recall works immediately on text/tags; the vector lands slightly later.
- Minimum: decouple embedding from the synchronous store path (
embed=async|sync, default async) so the write path never depends on provider latency.
- Complementary: return an explicit
pending_embedding state so the client knows the write succeeded and the vector is deferred.
Repro: smem_remember (MCP) with a ~1.5KB content → timed out after 30.0s; same content via smem remember --stdin → Remembered ... [type: insight] in one shot.
Context: We run surreal-memory as the production memory engine for our agent swarm (Uruboros), via both the stdio MCP server and the CLI. Full open cards.
Problem:
smem_rememberover the MCP interface reliably times out at the client's 30s tool-call cap (Claude Code / Claude Desktop) because the embedding is computed synchronously inside the write path (our embedding provider is a proxied Gemini endpoint). The identical write via the CLI (smem remember --stdin) succeeds — no 30s cap. Reproduced repeatedly 2026-07-08/09.Impact: A memory tool whose whole purpose is to prevent cross-session loss will silently drop writes on any MCP client with a bounded tool timeout: the agent "remembers", gets a timeout, and cannot tell whether the write landed. This is the exact failure mode the tool exists to prevent, and it affects any MCP host with a per-call timeout, not just our setup.
Suspected root cause: the embedding provider is awaited synchronously in
rememberbefore returning; a slow/remote provider (proxy, rate limit, cold start) pushes total latency past 30s.Proposed fix (open to discussion):
embedding_vec), return success, compute the embedding in a background task, and backfillembedding_vec+ reindex HNSW when ready. Recall works immediately on text/tags; the vector lands slightly later.embed=async|sync, default async) so the write path never depends on provider latency.pending_embeddingstate so the client knows the write succeeded and the vector is deferred.Repro:
smem_remember(MCP) with a ~1.5KB content →timed out after 30.0s; same content viasmem remember --stdin→Remembered ... [type: insight]in one shot.