Auto-add memories return status: failed (HTTP 200 but failed in body)

[benediktbluemelhuber]

Bug Report

Plugin version: 1.0.4
OpenClaw version: 2026.2.9

Problem

Automatic message logging (auto-add on each user message) returns HTTP 200 but with "status": "failed" in the response body.

Example Request

{
  "content": "[role: user]\n[Telegram Macher id:-1003541168386 topic:1 +1m Sun 2026-02-22 04:09 GMT+1] Benedikt B...",
  "containerTag": "openclaw_Mac_mini_von_Benedikt_local",
  "metadata": {
    "source": "openclaw",
    "timestamp": "2026-02-22T03:10:14.873Z"
  },
  "customId": "session_agent_main_telegram_group_1003541168386_topic_1"
}

Response (HTTP 200)

{
  "response": {
    "id": "VFscjj9mi9HL5CfnKemfqv",
    "status": "failed"
  },
  "type": "add"
}

Notes

• Explicit supermemory_store tool calls work fine and return success.
• Only the automatic per-message logging fails consistently.
• Visible in the Supermemory console dashboard.
• Possibly related to content length or format of raw Telegram messages with metadata.

[gwennypig]

same issue here, I also noticed that every add that fails also has the same id...

[JiwaniZakir]

The HTTP 200 with "status": "failed" pattern typically indicates the request passed API-level validation but was rejected during backend processing — likely by the memory storage layer rather than the request handler itself. The divergence between manual supermemory_store calls (which succeed) and the auto-add path strongly suggests the automatic logger is not applying the same content preprocessing that the explicit tool call does, such as stripping or escaping the bracketed Telegram metadata prefix ([role: user]\n[Telegram Macher id:...]). That format may be tripping a content validation rule or embedding pipeline step on the Supermemory side. Worth checking the auto-add handler (likely wherever the per-message hook fires) to see if it passes content through the same sanitization/truncation logic as the manual store path, particularly around the content field before it hits the /v1/memories endpoint.