You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
saveGraph writes lines.join("\n") without a trailing newline. The JSONL spec requires every record to be terminated by \n. This makes the output non-conformant and fragile.
The problem
saveGraph produces a file where the last line has no terminating \n:
{"type":"entity","name":"Alice","entityType":"person","observations":["test"]}
{"type":"relation","from":"Alice","to":"Bob","relationType":"knows"} <-- no \n
Unexpected non-whitespace character after JSON at position 88 (line 1 column 89)
How I hit this
I run the memory server across multiple concurrent sessions pointing at the same memory.jsonl file. After several days I found a line with two JSON objects concatenated. Every tool call returned the parse error above until I manually edited the file.
The root cause is likely the race condition described in #2579: multiple MCP server instances calling saveGraph concurrently on the same file. #3286 addresses that with cross-process file locking and atomic writes, which is the proper fix.
This PR does not solve the race condition. It makes the output JSONL-spec-conformant, which is correct regardless of whether #3286 lands.
loadGraph already filters empty lines (filter(line => line.trim() !== "")), so the trailing \n has no side effects on read.
Tests
Three new tests in knowledge-graph.test.ts:
Trailing newline check: verifies the file ends with \n.
Per-line validity: verifies every non-empty line parses as valid JSON individually.
External append simulation: writes entities via saveGraph, appends a line via fs.appendFile, then reads back via a fresh KnowledgeGraphManager instance. This test fails without the fix and passes with it.
Correct. This is the right fix. loadGraph already handles trailing newlines gracefully via .filter(line => line.trim() !== "") at line 74, so the read path is unaffected.
Minor edge case — empty graph: When all entities and relations are deleted, lines = [], so lines.join("\n") + "\n" writes "\n" (a single newline) instead of an empty file. Previously it would write "". The load path handles this correctly, but it does mean that after deleting everything, the file contains one blank line rather than nothing. Not a blocking concern, but worth noting.
Three new tests are added to the file persistence describe block.
"should write a trailing newline to produce valid JSONL" (line 429) — Minimal and direct. Exactly right.
"should produce a file where every line is individually valid JSON" (line 438) — The logic is sound and the loop that validates each non-empty line individually is a good defensive check. However, the block comment spanning lines 439–448 is unusually verbose for production test code — it re-explains the bug in prose that belongs in the PR description, not the test. Consider trimming to one line, or removing it entirely since the test name is already self-describing.
"should not corrupt JSONL when content is appended to the file externally" (line 465) — This is the most valuable test: it models the exact failure mode described in the PR. Creating a second KnowledgeGraphManager to force a fresh loadGraph from disk is the right approach. Same feedback applies to the lengthy comment block (lines 468–488).
Pre-existing test at line 412 ("should handle JSONL format correctly") — Note that this test already filters out the trailing empty string produced by splitting on \n, so it would still pass even without this fix. The new trailing-newline test at line 429 is what actually pins the fix in place. This is fine; just clarifying the test coverage picture.
Overall
The fix is correct, minimal, and addresses a real spec compliance issue. The three new tests adequately cover the change. The only nit is the long explanatory comment blocks inside the tests — those are better suited to the PR description (where they already exist) than to the source code.
Approve when ready. No blocking issues.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bugSomething isn't workingserver-memoryReference implementation for the Memory MCP server - src/memory
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
saveGraphwriteslines.join("\n")without a trailing newline. The JSONL spec requires every record to be terminated by\n. This makes the output non-conformant and fragile.The problem
saveGraphproduces a file where the last line has no terminating\n:A JSONL file should look like this:
The missing terminator means any tool or process that appends to the file (log rotation, crash recovery, file concatenation) produces invalid JSONL:
JSON.parse()then throws on that line:How I hit this
I run the memory server across multiple concurrent sessions pointing at the same
memory.jsonlfile. After several days I found a line with two JSON objects concatenated. Every tool call returned the parse error above until I manually edited the file.The root cause is likely the race condition described in #2579: multiple MCP server instances calling
saveGraphconcurrently on the same file. #3286 addresses that with cross-process file locking and atomic writes, which is the proper fix.This PR does not solve the race condition. It makes the output JSONL-spec-conformant, which is correct regardless of whether #3286 lands.
Fix
loadGraphalready filters empty lines (filter(line => line.trim() !== "")), so the trailing\nhas no side effects on read.Tests
Three new tests in
knowledge-graph.test.ts:\n.saveGraph, appends a line viafs.appendFile, then reads back via a freshKnowledgeGraphManagerinstance. This test fails without the fix and passes with it.All 48 tests pass. No existing tests affected.
Related
mcp-server-memoryFailures due to Race Condition and Environment Misconfiguration #2579: the race condition that causes JSONL corruption with concurrent instancesproper-lockfile(open, the full fix)