Repository navigation
DELETE /api/v1/memories does not cascade to derived memories (episodic, foresight, event_log) #148
Description
Activity
The root cause is straightforward:
MemCellDeleteService.delete_by_combined_criteriaperforms the soft-delete onMemCelldocuments but never invokes the downstream repository delete methods, leaving derived records orphaned across MongoDB, Elasticsearch, and Milvus. The fix requires wiring the existing cascade infrastructure —EpisodicMemoryEsRepository.delete_by_event_id,ForesightMilvusRepository.delete_by_parent_id, and their equivalents — into that service method, usingmemcell_event_id_listto resolve the parent-child relationship before (or immediately after) theMemCell.delete_many(filter_dict)call. Worth noting that since Elasticsearch and Milvus deletes are separate I/O operations, the cascade should handle partial failure gracefully to avoid a state where some stores are cleaned up but others are not.Closing this as part of the EverOS 1.0 issue triage. This issue references the pre-1.0 API or retired infrastructure such as /api/v1/memories, /api/v3/agentic/*, MongoDB, Elasticsearch, Milvus, Redis, Kafka, longjob, or old memory type names. EverOS 1.0 uses POST /api/v1/memory/{add,flush,search,get} with Markdown + SQLite + LanceDB. Migration notes are tracked in PR #258: #258. If the same behavior still occurs on current main with the 1.0 API, please open a fresh issue with a 1.0 repro.
Reacted by MarkPost-triage verification: keeping this closed because the reported DELETE /api/v1/memories cascade path belongs to the retired pre-1.0 MongoDB/ES/Milvus stack. The broader 1.0 memory lifecycle question is not being ignored; delete/reset/rollback APIs are still tracked in open issue #14.
Summary
DELETE /api/v1/memoriessoft-deletesMemCelldocuments in MongoDB but does not cascade to derived memory types. After deletion,episodic_memory,foresight_record, andevent_log_recorddocuments remain in MongoDB, Elasticsearch, and Milvus — and continue to appear in search results.Steps to Reproduce
POST /api/v1/memoriesuntil boundary detection triggers extractionGET /api/v1/memories/searchDELETE /api/v1/memorieswithevent_idset to the MemCell_idExpected Behavior
Deleting a MemCell should cascade to all derived records:
The repository classes already have the necessary delete methods (
EpisodicMemoryEsRepository.delete_by_event_id,ForesightMilvusRepository.delete_by_parent_id, etc.) — they just aren't called fromMemCellDeleteService.delete_by_combined_criteria.Actual Behavior
MemCellDeleteService.delete_by_combined_criteriaonly callsMemCell.delete_many(filter_dict). No derived memories are touched. The cascade delete infrastructure (repository delete methods) exists but is not wired into the delete service.Additional Context
memcell_event_id_listfield on derived memories provides the link back to the parent MemCell, which could be used for cascade lookups3c9a2d0246