Bug: /insights 500 Invocation stopped — trailing garbage bytes appended to mem:insights.bin

Bug: GET /agentmemory/insights fails with Invocation stopped — trailing garbage bytes appended to mem:insights.bin

Version: @agentmemory/[email protected], iii-engine 0.11.2 (pinned) OS: Windows 11 (native iii.exe, pm2 daemon) Corpus: ~2,640 insights, bin file ~124 MB

Symptom

GET /agentmemory/insights?limit=300 (and any limit, including limit=1) returns 500 {"error":"Invocation stopped"} for 3+ consecutive days, while every sibling endpoint (/health, /slots, /sessions, /graph/stats, /search, /session/start) returns 200. REFLECT generation itself is healthy (consolidation log shows reflect.success:true, newInsights:5 every round, usedFallback:false), and the bin file keeps being written — only the read path is broken.

Root cause

data/state_store.db/mem%3Ainsights.bin is a single monolithic JSON object (2,638 keys). The JSON body itself is valid, but 8–12 garbage bytes (incl. 0x00, 0x1D, non-UTF-8 bytes) are appended after the final }}, e.g. tail hex:

... 32 30 32 36 2d 30 39 2d 31 32 54 ... 22 7d 7d 00 00 96 2f 9f 1d 28 34 98 f8
                                             ^^^^ valid end ^^  ^^^^^^^^^^^^^ garbage

The read path does a strict whole-file JSON.parse, which throws on the trailing bytes → invocation aborts → REST 500. Verified locally: truncating the file at the last }} makes JSON.parse pass on all 2,643 keys.

The garbage was appended by the write side, repeatedly and with varying length (observed 8-byte and 10/12-byte variants at different times), so this looks like a partial/concurrent-write artifact in the file-based KV persistence rather than one-off disk corruption.

Workaround (verified)

1. Back up the bin file.
2. Truncate everything after the last valid }}.
3. Restart the daemon (pm2 restart agentmemory iii-engine) — required because the engine serves reads from its in-memory copy loaded at boot; the file fix alone does not restore the endpoint until restart.

After this, /insights returns 200 in milliseconds with fresh data.

Suggested fix

• Write path: make the bin persistence atomic (write-temp + rename) or at least truncate-then-write so partial appends cannot leave trailing bytes.
• Read path: consider a tolerant parse (e.g. parse up to last valid }}) or surface a clear "store file corrupt at byte N" error instead of bare Invocation stopped, which is indistinguishable from load timeouts.

Happy to provide the backed-up corrupt file (124 MB) or test a patch.