Supermemory strips NUL from content, so the provider round-trip case fails against the live service

[YellowSnnowmann]

Summary

Supermemory strips the NUL character (U+0000) from content server-side, so assert_provider's round-trip-fidelity case fails against the live service. The adapter is not at fault — the API alters the content before storing it — but the conformance suite is right to fail, and the driver currently makes a promise the engine does not keep.

Found by running the suite against the real https://api.supermemory.ai rather than the double.

Evidence

Not inferred from a read-back. The creation response itself echoes the mangled value — a two-letter string sent with a NUL between the letters comes back as the two letters alone:

POST https://api.supermemory.ai/v4/memories
{"memories":[{"content":"a<NUL>b","isStatic":false,"metadata":{}}],"containerTag":"..."}

201 Created
{"documentId":"...","memories":[{"id":"...","memory":"ab", ...}]}

Three characters in, two stored. The double never modelled this, because it was written from the same documentation the adapter was — which is the general hazard rather than a criticism of the double.

The failing assertion

tinymemory-conformance/src/suite/mod.rs, the newlines case (its literal carries \n, \r\n and a NUL):

supermemory: `newlines` content was mangled
  left:  "a\nb\r\ncd"
  right: "a\nb\r\nc<NUL>d"

The suite's own comment explains why this must fail rather than be tolerated: a driver may refuse content, but silently altering it is exactly what the assertion exists to catch.

Who this does and does not affect

It does not reach OpenCompany, and saying so keeps the fix from being scoped wrongly. Its facades JSON-encode every record into content, so a NUL inside a trace, fact or chunk crosses the wire as the six ASCII characters of its JSON escape and arrives as text there is nothing to strip. Verified rather than assumed: with the provider contract failing, that same live service passes OpenCompany's full port suite — ContextStore / FactStore / MemoryStore round-trips and the (addr, label) semantics included (opencompany#1557).

It does affect any consumer that hands the driver raw text. MemoryCore::store promises that what you store is what you get back, and against Supermemory that is untrue for this character.

Options

1. Document it. Note in the Supermemory adapter that NUL does not survive, and give the conformance case a driver-scoped exemption with the reason attached. Cheapest and honest, but it weakens a suite whose whole value is that it does not bend.
2. Refuse it. Reject content containing NUL from the Supermemory adapter with MemoryError::Invalid. The suite already accepts a refusal — "may refuse" is its documented alternative to storing faithfully — so this passes without weakening the assertion, and the caller learns at the boundary instead of discovering it later.
3. Encode it. Escape NUL on write and unescape on read inside the adapter. Round-trip becomes true, at the cost of content in the vendor's own UI no longer matching what the caller sent, and of a scheme every other reader of that account would have to know.

Option 2 reads best to me: it keeps the contract meaning what it says, and turns silent data loss into a refusal the caller can act on. The call belongs to whoever owns the adapter's compatibility posture.

Reproducing

OPENCOMPANY_TEST_SUPERMEMORY_URL=https://api.supermemory.ai \
OPENCOMPANY_TEST_SUPERMEMORY_KEY=... \
  cargo test --features tinymemory --lib live_hosted

from opencompany#1557, which added the live-service lane. Without the pair it skips, so an offline run is unaffected.

Related

• Remote + embedded audit at v1.1.0: Supermemory re-store 400s (PATCH drops containerTag), keyed-seam gaps, and verified adapter defects #75 — the v1.1.0 remote + embedded audit, which found the Supermemory PATCH dropping containerTag. Same adapter, same class of defect: one only a real endpoint reveals.

[YellowSnnowmann]

Fixed in #81 (draft). Measuring the defect rather than reasoning from the one character I first hit changed the shape of it twice, so both corrections belong here:

It is two characters, not one. U+FFFD is stripped as well as U+0000. Probing the whole C0 range plus DEL, NEL, ZWSP, BOM and U+2028 in a single record showed everything else survives — including U+0001, which rules out "control characters get sanitised" as the explanation. So the refusal is exactly two characters wide, with a test pinning the negative half; a refusal broadened to control characters would reject content Supermemory stores perfectly well.

U+FFFD matters more than U+0000 in practice. NUL in text content is nearly always binary leakage, but the replacement character arrives in any text that has been through a lossy decode, so real callers will meet this.

Only content is affected, and that is load-bearing. Metadata is not sanitised: tinymemory_key, tinymemory_namespace and tinymemory_session_id all round-trip both characters intact through store and search. Worth stating because the alternative was worse than mangled content — identity travels in metadata, so had it been sanitised too, a re-store would have stopped matching its own record and duplicated it instead, with get and forget never finding it. The refusal is therefore scoped to content, with a test asserting identity is still accepted so widening it later has to re-measure first.

The recommendation in the issue stands and is what #81 implements: refuse with MemoryError::Invalid. The suite already accepts a refusal as the documented alternative to storing faithfully, so it passes without the assertion being weakened, and silent data loss becomes something the caller can act on.

#81 also adds the env-gated live target this was found with. That is the more general fix: every adapter test here runs against a double written from the same documentation the adapter was, so a service that departs from its documentation leaves adapter and double wrong together with the suite still green. Verified non-vacuous by reverting only the adapter change and re-running against the live API — it fails there with exactly the assertion quoted above, and passes with the fix.

Still open: whether Mem0 and Cognee have their own equivalents. The lane covers all three, but only Supermemory credentials were to hand, so the other two are unverified rather than known-good.