Bug Description
write_note and edit_note always report checksum: unknown in their MCP responses, even though a real SHA-256 checksum for the note exists and is persisted in the database. The value simply isn't carried into the response model.
Steps To Reproduce
Against a basic-memory mcp --transport streamable-http server, v0.23.2:
Response:
# Created note
project: main
file_path: probe/Checksum Probe.md
permalink: main/probe/checksum-probe
checksum: unknown <-- always
Same for every edit_note operation (append, replace_section, …).
Meanwhile the checksum is present in memory.db:
sqlite> SELECT title, checksum FROM entity LIMIT 3;
Agent Files System | 91660a2e382281cacbbcf8e03d9f423aa57e6fd9c29dcdeb5d5fe676f48bc0ff
Agent Prompts | 1a49aec7bfbad3dfcc616b7cb5392345cd0a724c4754eaac703c8e87c1ccadf3
Finance | 3cd2723e4054a259ba4ca2e33c4c342bc74d115bf5cf74e4ac1c7120ce488379
Expected Behavior
The response shows the first 8 characters of the note's checksum, as the formatting code clearly intends:
# src/basic_memory/mcp/tools/write_note.py:552
f"checksum: {result.file_checksum[:8] if result.file_checksum else 'unknown'}",
# src/basic_memory/mcp/tools/edit_note.py:793, :804
f"checksum: {result.checksum[:8] if result.checksum else 'unknown'}",Actual Behavior
result.file_checksum / result.checksum is None on every call, so the fallback string is always taken. unknown is never not printed.
Why it matters
Beyond the cosmetic wart, the checksum is the only value in the response that lets a caller confirm which version of a note it just wrote. Agents that edit notes concurrently (or that retry after a timeout) have no way to detect a lost update from the tool output alone. Advertising the field and never populating it is worse than omitting it, because it reads as "this note has no checksum".
Environment
- OS: Ubuntu 24.04
- Python: 3.13 (container)
- Basic Memory: 0.23.2 (
ghcr.io/basicmachines-co/basic-memory:latest)
- Installation: Docker, streamable-http transport
- Backend: SQLite
Possible Solution
The checksum is computed and stored during the write/sync path but is not propagated back through the response schema returned to the MCP tool. Populating file_checksum / checksum on that response object (or reading it back from the persisted entity before formatting the response) should be enough.
Happy to open a PR if you can point me at which of the two is the intended source of truth for the response value.
Bug Description
write_noteandedit_notealways reportchecksum: unknownin their MCP responses, even though a real SHA-256 checksum for the note exists and is persisted in the database. The value simply isn't carried into the response model.Steps To Reproduce
Against a
basic-memory mcp --transport streamable-httpserver, v0.23.2:Response:
Same for every
edit_noteoperation (append,replace_section, …).Meanwhile the checksum is present in
memory.db:Expected Behavior
The response shows the first 8 characters of the note's checksum, as the formatting code clearly intends:
Actual Behavior
result.file_checksum/result.checksumisNoneon every call, so the fallback string is always taken.unknownis never not printed.Why it matters
Beyond the cosmetic wart, the checksum is the only value in the response that lets a caller confirm which version of a note it just wrote. Agents that edit notes concurrently (or that retry after a timeout) have no way to detect a lost update from the tool output alone. Advertising the field and never populating it is worse than omitting it, because it reads as "this note has no checksum".
Environment
ghcr.io/basicmachines-co/basic-memory:latest)Possible Solution
The checksum is computed and stored during the write/sync path but is not propagated back through the response schema returned to the MCP tool. Populating
file_checksum/checksumon that response object (or reading it back from the persisted entity before formatting the response) should be enough.Happy to open a PR if you can point me at which of the two is the intended source of truth for the response value.