SupermemoryOpenAIWrapper wraps client.chat.completions.create(). With default
configuration (just container_tag and custom_id, which are both required
anyway; mode defaults to "profile", add_memory defaults to "always"), every
single create() call triggers an unconditional network request to
api.supermemory.ai via add_system_prompt() -> supermemory_profile_search().
That call chain has no error handling anywhere: no try/except around it,
no timeout guard, no fail-open fallback. If Supermemory's API is down,
rate-limited, times out, or has any network hiccup, the entire chat
completion call fails with an unhandled exception, even though the
underlying OpenAI call is completely unaffected.
Confirmed in both the sync and async paths, via both mocked and real
network failures.
Repro (async path):
client = AsyncOpenAI(api_key="...")
opts = OpenAIMiddlewareOptions(container_tag="user123", custom_id="conv1")
wrapped = SupermemoryOpenAIWrapper(client, opts)
# Simulate Supermemory being unreachable
with patch("aiohttp.ClientSession.post", side_effect=aiohttp.ClientConnectionError()):
await client.chat.completions.create(messages=[{"role": "user", "content": "hello"}])
# raises ClientConnectionError -- the LLM call never happens
Notably, this same file already implements the correct pattern elsewhere:
add_memory_tool (the memory-write path) is carefully wrapped in a broad
try/except that catches SupermemoryNetworkError, SupermemoryAPIError, and
generic exceptions, logs, and continues. The memory-search path
(add_system_prompt, which runs on every call by default) has no equivalent
protection at all.
Any production app using this middleware becomes fully dependent on
Supermemory's uptime for its core LLM functionality to keep working, which
seems like the opposite of what a lightweight middleware wrapper should
guarantee.
SupermemoryOpenAIWrapper wraps client.chat.completions.create(). With default
configuration (just container_tag and custom_id, which are both required
anyway; mode defaults to "profile", add_memory defaults to "always"), every
single create() call triggers an unconditional network request to
api.supermemory.ai via add_system_prompt() -> supermemory_profile_search().
That call chain has no error handling anywhere: no try/except around it,
no timeout guard, no fail-open fallback. If Supermemory's API is down,
rate-limited, times out, or has any network hiccup, the entire chat
completion call fails with an unhandled exception, even though the
underlying OpenAI call is completely unaffected.
Confirmed in both the sync and async paths, via both mocked and real
network failures.
Repro (async path):
Notably, this same file already implements the correct pattern elsewhere:
add_memory_tool (the memory-write path) is carefully wrapped in a broad
try/except that catches SupermemoryNetworkError, SupermemoryAPIError, and
generic exceptions, logs, and continues. The memory-search path
(add_system_prompt, which runs on every call by default) has no equivalent
protection at all.
Any production app using this middleware becomes fully dependent on
Supermemory's uptime for its core LLM functionality to keep working, which
seems like the opposite of what a lightweight middleware wrapper should
guarantee.