[superlog] Fix supermemory container tag format in storeAnalyticsSummary

[superlog-app]

Summary

The storeAnalyticsSummary function in packages/ai/src/lib/supermemory.ts was calling client.add() with two invalid parameters, causing every weekly analytics summary write to fail with a 400 error from the supermemory API:

Cannot extract content: All extractors rejected. web: Content is not a valid URL

Root cause: The function used containerTags: ['website:${websiteId}'] — the deprecated plural-array parameter (SDK v4 replaced this with singular containerTag: string) — and the value contained a colon (:) which violates the API's documented constraint of alphanumeric/hyphens/underscores/dots only. With an invalid/ignored container tag the server falls back to URL extraction on the plain-text content and fails.

Fix: Migrate to containerTag: \website_${websiteId}`(singular string, underscore separator) and applysanitizeMemoryContent() to stay within the 2 000-char content limit. The other memory helpers (storeConversation, saveCuratedMemory`) have the same colon-in-tag pattern but swallow errors silently — those can be migrated in a follow-up.

Incident on Superlog

---

Was this PR helpful? Leave feedback — goes straight to the Superlog team.

---

Summary by cubic

Fixes failing weekly analytics summary writes to supermemory by using the correct containerTag and sanitizing content to prevent 400 errors. storeAnalyticsSummary writes now succeed.

• Bug Fixes
  • Replace deprecated containerTags with containerTag and set value to website_${websiteId} (no colon) to meet API rules.
  • Apply sanitizeMemoryContent(summary) to keep content within size limits.

^{Written for commit 004e392. Summary will update on new commits.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
databuddy-status	Ready	Preview, Comment	Jun 13, 2026 9:24am

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
dashboard	Skipped		Jun 13, 2026 9:24am
documentation	Skipped		Jun 13, 2026 9:24am

[unkey-deploy]

The latest updates on your projects. Learn more about Unkey Deploy

Name	Status	Preview	Inspect	Updated (UTC)
api (preview)	Ready	Visit Preview	Inspect	Jun 13, 2026 9:25am

[greptile-apps]

Greptile Summary

This PR fixes an active 400 error in storeAnalyticsSummary by replacing the deprecated containerTags array (with an invalid colon-separated value) with the correct singular containerTag string and applying sanitizeMemoryContent() for the 2 000-char limit.

• The write-side fix is correct: the API call now uses a valid parameter name and a tag format that meets the alphanumeric/hyphens/underscores/dots constraint.
• However, storeAnalyticsSummary stores into the website_${websiteId} container while all read paths (getMemoryContext, searchMemories) query only user- or apikey-scoped containers — meaning stored summaries remain unreachable by the AI assistant.
• buildContainerTags and primaryContainerTag still emit colon-format tags used by both the deferred write helpers and every active read call; if the API validates tags on reads too, memory retrieval for all chat sessions may also be silently failing.

Confidence Score: 3/5

The write-side fix is correct and resolves the immediate 400 error, but the analytics summary feature remains end-to-end broken because stored summaries land in a container the AI never reads from.

The two-line change correctly repairs the supermemory API call, but stored summaries go into a website_* container while every retrieval path exclusively queries user- and apikey-scoped containers. Additionally, the colon-format tags still used by primaryContainerTag on the live read path may be causing silent failures on all memory retrievals.

packages/ai/src/lib/supermemory.ts — specifically the container tag used in storeAnalyticsSummary versus those queried by getMemoryContext and searchMemories, and the colon-format tags still produced by buildContainerTags and primaryContainerTag.

Important Files Changed

Filename	Overview
packages/ai/src/lib/supermemory.ts	Fixes the 400 error in storeAnalyticsSummary by switching to the singular containerTag API and sanitizing content, but stores summaries in a website_* container that no existing read path queries, leaving the feature still non-functional end-to-end.

Sequence Diagram

sequenceDiagram
    participant Insights as apps/insights generation.ts
    participant Store as storeAnalyticsSummary
    participant SM as Supermemory API
    participant Agent as AI Agent
    participant Read as getMemoryContext / searchMemories

    Note over Insights,SM: Write path (after this fix)
    Insights->>Store: summary, site.id
    Store->>SM: client.add containerTag website_siteId
    SM-->>Store: 200 OK

    Note over Agent,SM: Read path (unchanged)
    Agent->>Read: query, userId, apiKeyId
    Read->>SM: containerTag user_userId or apikey_apiKeyId
    SM-->>Read: results from user/apikey container
    Read-->>Agent: memories — analytics summaries never returned

    Note over Store,Read: Mismatch — writes go to website_* container, reads query user:* / apikey:* containers only

Loading

Comments Outside Diff (1)

1. packages/ai/src/lib/supermemory.ts, line 30-61 (link)

   Colon-format tags still used for reads and conversation writes

   buildContainerTags and primaryContainerTag both produce values like user:${userId} and apikey:${apiKeyId} that contain the colon character documented as invalid. storeConversation and saveCuratedMemory call buildContainerTags on the write path (failures swallowed silently), and getMemoryContext/searchMemories call primaryContainerTag on every read. If the API enforces the alphanumeric/hyphens/underscores/dots constraint on reads as well as writes, memory retrieval for every chat session is also silently returning empty results. The PR description defers this to a follow-up, but it's worth confirming the reads don't also 400 before shipping.

_{Reviews (1): Last reviewed commit: "[superlog] Fix supermemory container tag..." | Re-trigger Greptile}

[greptile-apps]

Analytics summaries stored in unreachable container

storeAnalyticsSummary now writes into container website_${websiteId}, but every read path — getMemoryContext (line 80) and searchMemories (line 223) — uses primaryContainerTag(userId, apiKeyId) which only ever returns user:${userId}, apikey:${apiKeyId}, or "anonymous". No call site ever queries a website_*-prefixed container, so the summaries generated by apps/insights/src/generation.ts are stored successfully but will never be surfaced in AI responses. The feature is still functionally inert, just silently so instead of erroring.