Bug Description
On an ordinary Basic Memory Cloud note with no review items, edit_note(operation="find_replace") accepted an outdated expected_checksum and modified the note.
Paul suggested in Discord that this looks like a core-library bug.
Steps To Reproduce
The observed test used a disposable synthetic note:
- Read the note using structured
read_note and save its revision_checksum as cA.
- Append a marker, producing revision B.
- Read again and confirm its checksum differs from cA.
- Confirm the original replacement target still occurs exactly once in B.
- Call
edit_note on the same note with:
operation="find_replace"- The original target as
find_text
- Replacement content
expected_replacements=1expected_checksum=cA
- Read the note again to check whether the stale edit was rejected.
Expected Behavior
The stale precondition rejects the mutation with a recognizable conflict error. Revision B and its contents remain unchanged.
If checksum preconditions are unsupported on ordinary notes, supplying one should return an explicit error rather than silently proceed.
Actual Behavior
The replacement succeeded, and read-back confirmed the content changed.
Observed checksum prefixes:
- Baseline A:
eaec17de…
- After marker append B:
b3aa17dc…
- After accepted stale edit:
bb60d282…
The replacement target occurred exactly once, so replacement-count validation did not explain or prevent the stale edit. The appended marker and the note's identity remained intact.
Environment
- Basic Memory Cloud through its ChatGPT connector
- Observed September 11, 2026
- Cloud server/core-library version: unknown
- No local Basic Memory installation was used for this test
- Disposable synthetic note with no review items; no production data involved
Additional Context
An automated reader can submit an edit based on outdated content while believing its supplied checksum protects against concurrent changes.
Our current workaround is an exclusive overnight maintenance window. No production data was lost in this test.
The MCP documentation describes expected_checksum in the context of reviewed notes. Please confirm whether accepting a stale checksum on an ordinary note is intended.
This sequential test demonstrates stale acceptance; it does not establish behavior under simultaneous racing writes.
Reference: https://docs.basicmemory.com/reference/mcp-tools-reference
Possible Solution
When an expected_checksum is supplied, enforce it on ordinary notes as well as reviewed notes, or explicitly reject it if unsupported. Validation and commit should be atomic so another writer cannot change the note between checking the checksum and saving.
A regression test should confirm stale rejection without mutation. A separate concurrency test could verify that two conditional writes based on the same revision produce exactly one success and one conflict.
Bug Description
On an ordinary Basic Memory Cloud note with no review items,
edit_note(operation="find_replace")accepted an outdatedexpected_checksumand modified the note.Paul suggested in Discord that this looks like a core-library bug.
Steps To Reproduce
The observed test used a disposable synthetic note:
read_noteand save itsrevision_checksumas cA.edit_noteon the same note with:operation="find_replace"find_textexpected_replacements=1expected_checksum=cAExpected Behavior
The stale precondition rejects the mutation with a recognizable conflict error. Revision B and its contents remain unchanged.
If checksum preconditions are unsupported on ordinary notes, supplying one should return an explicit error rather than silently proceed.
Actual Behavior
The replacement succeeded, and read-back confirmed the content changed.
Observed checksum prefixes:
eaec17de…b3aa17dc…bb60d282…The replacement target occurred exactly once, so replacement-count validation did not explain or prevent the stale edit. The appended marker and the note's identity remained intact.
Environment
Additional Context
An automated reader can submit an edit based on outdated content while believing its supplied checksum protects against concurrent changes.
Our current workaround is an exclusive overnight maintenance window. No production data was lost in this test.
The MCP documentation describes
expected_checksumin the context of reviewed notes. Please confirm whether accepting a stale checksum on an ordinary note is intended.This sequential test demonstrates stale acceptance; it does not establish behavior under simultaneous racing writes.
Reference: https://docs.basicmemory.com/reference/mcp-tools-reference
Possible Solution
When an
expected_checksumis supplied, enforce it on ordinary notes as well as reviewed notes, or explicitly reject it if unsupported. Validation and commit should be atomic so another writer cannot change the note between checking the checksum and saving.A regression test should confirm stale rejection without mutation. A separate concurrency test could verify that two conditional writes based on the same revision produce exactly one success and one conflict.