What happened?
mempalace_memories_filed_away accepts any value returned by json.loads() from ~/.mempalace/hook_state/last_checkpoint, deletes the acknowledgement marker, and then assumes the decoded value is an object.
A syntactically valid checkpoint containing null, an array, a string, a number, or a boolean therefore raises AttributeError on .get() after the one-shot marker has already been consumed. MCP clients receive an internal tool error and cannot retry the acknowledgement.
Malformed JSON syntax already follows a stable fail-soft contract: consume the marker and return status: error. Valid non-object JSON roots fall through that guard.
What did you expect?
Treat a decoded checkpoint as usable only when it is a JSON object. Non-object roots should follow the existing malformed-checkpoint outcome:
- consume the acknowledgement marker;
- return
status: error, count: 0, and timestamp: null;
- never echo the rejected payload;
- preserve the existing valid-object and missing-file behavior.
How to reproduce:
- Write any of these values to
last_checkpoint: null, [], "text", 42, or true.
- Call
mempalace_memories_filed_away.
- Observe
AttributeError: '<type>' object has no attribute 'get' after the file has been unlinked.
The same result is reproducible for all five JSON root types on current develop (06cb698).
Environment:
- OS: macOS (the failure is platform-independent)
- Python version: 3.14
- MemPal version:
develop at 06cb6987f02610784fefbad4b2bd5d026d164ba6
Scope note: this report is specifically about valid non-object JSON roots. Invalid UTF-8, unlink races/failures, and malformed fields inside an object are separate concerns.
What happened?
mempalace_memories_filed_awayaccepts any value returned byjson.loads()from~/.mempalace/hook_state/last_checkpoint, deletes the acknowledgement marker, and then assumes the decoded value is an object.A syntactically valid checkpoint containing
null, an array, a string, a number, or a boolean therefore raisesAttributeErroron.get()after the one-shot marker has already been consumed. MCP clients receive an internal tool error and cannot retry the acknowledgement.Malformed JSON syntax already follows a stable fail-soft contract: consume the marker and return
status: error. Valid non-object JSON roots fall through that guard.What did you expect?
Treat a decoded checkpoint as usable only when it is a JSON object. Non-object roots should follow the existing malformed-checkpoint outcome:
status: error,count: 0, andtimestamp: null;How to reproduce:
last_checkpoint:null,[],"text",42, ortrue.mempalace_memories_filed_away.AttributeError: '<type>' object has no attribute 'get'after the file has been unlinked.The same result is reproducible for all five JSON root types on current
develop(06cb698).Environment:
developat06cb6987f02610784fefbad4b2bd5d026d164ba6Scope note: this report is specifically about valid non-object JSON roots. Invalid UTF-8, unlink races/failures, and malformed fields inside an object are separate concerns.