Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

memory: add POST /api/v2/memory/delete so everos-mcp forget_session works on self-hosted servers

Aperta
  • Qualcosa non va?
#483 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
python, sqlite
Ambito
api, backend, databases

Direzione di ricerca

Design work, not a first task. The issue says the Cloud side is a placeholder and the three open questions (derived-data handling, cascade through the markdown/SQLite/LanceDB stores, filter semantics) are unresolved. Read the existing cascade path for deleted change events in this repo to see how a batch delete would reuse it. Done means those questions are answered in the issue thread and the POST /api/v2/memory/delete contract is agreed with the maintainers.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Context

The official MCP server everos-mcp has a forget_session tool. It sends POST /api/v2/memory/delete with {app_id, project_id, session_id} and no owner, then reads data.count from the response. Self-hosted EverOS has no such route, so the tool degrades to "this deployment does not support deleting memories through the API" (verified 2026-10-10). Nothing crashes, but self-hosted users cannot delete through MCP.

Update 2026-10-28: the Cloud contract is settled

The first version of this issue described the Cloud endpoint as a placeholder: 204, a three-state filter, and a sender_id field. That description was copied from an outdated Cloud API reference. Cloud has a real implementation, extended on 2026-10-16. The contract to align with is:

  • POST /api/v2/memory/delete, success 200, response data = {filters: [...], count: int}. filters lists the scope fields that were applied. count is the number of memory records deleted; source messages are not counted.
  • Body: app_id / project_id (default "default", never matched across apps or projects), user_id XOR agent_id, and session_id. At least one of user_id / agent_id / session_id is required. A field that is sent filters; a field that is omitted does not. There is no three-state filter and no sender_id.
Scope Memories deleted Session source (pending buffer, memcells, session record)
session_id only episode, atomic_fact, foresight, agent_case of that session Deleted too
user_id episode, atomic_fact, foresight, profile of that user Kept
user_id + session_id episode, atomic_fact, foresight (no profile) Kept
agent_id (± session_id) agent_case, plus agent_skill when agent_id is alone Kept

Only a session-only delete removes the source, because the buffer and memcells belong to every participant of the session. An owner-scoped delete removes what has been extracted so far. Messages not yet flushed will still be extracted later. After a session-only delete:

  • flush on that session returns no_extraction.
  • The delete is serialized with add / flush on the same session. A busy session returns a retryable 503, and nothing is deleted.
  • The same session_id can keep receiving add calls; they are treated as a new conversation.

Not touched (known boundaries): clusters, Reflection-merged episodes, and the profile under any delete that carries session_id.

forget_session uses the session-only shape, so that row is the one self-hosted EverOS needs first.

What self-hosted EverOS is missing

Cloud behaviour EverOS storage Status
Route + DeleteInput / DeleteData entrypoints/api/routes/ has add / flush / search / get only Missing
Delete episode, atomic_fact, foresight, agent_case of the session Daily-log Markdown: users/<id>/{episodes,.atomic_facts,.foresights}/, agents/<id>/agent_cases/. Every entry carries session_id. Missing: an operation that removes the matching entries from a file under the writer's existing per-path lock. The index side already works: when a daily-log file is modified, the cascade drops the LanceDB rows of entries that disappeared from it (memory/cascade/handlers/_daily_log_base.py).
Find what to delete Files are named by the date they were written, so one session can span several files and, for a session-only delete, several owners Open: query LanceDB by session_id to get md_path (fast, but may miss an entry written in the last moment before indexing) or scan the Markdown (always complete, cost grows with the memory root)
Delete pending buffer SQLite unprocessed_buffer Missing
Delete memcells SQLite memcell. payload_json holds the full transcript; nothing else removes it. Missing
Delete session record SQLite conversation_status (window pointer) Missing
Serialize with add / flush service/_session_lock.py (per-process lock, matching the single-instance assumption) Reuse
Stop in-flight extraction from writing back OME strategies (extract_atomic_facts, extract_foresight, extract_agent_case, trigger_profile_clustering) write from the event payload and never re-check whether the source still exists Missing: a liveness check right before the write
Async queue (EverOS only) SQLite memorize_inbox. A queued row accepted before the delete replays the conversation after it. A failed row keeps the request body for row_retention_hours (168h). Open: cancel the session's queued rows, or wait for them
Owner-scoped delete Profile users/<id>/user.md; skills agents/<id>/skills/ (AgentSkillWriter.delete_skill exists) Missing; everos-mcp does not need it

One difference from Cloud: re-importing identical content (same sender, timestamp and text) after a session delete produces no memories on Cloud, because Cloud derives memcell ids from content. EverOS memcell ids are random (mc_<uuid>), so the same import would be extracted again.

Open questions

  1. Scope of the first version: session-only (what everos-mcp needs), or the full contract including owner-scoped deletes.
  2. How to find the affected Markdown files: index lookup or Markdown scan (see the table).
  3. What happens to queued async requests of the deleted session.
  4. Whether identical content re-imported after a delete should stay deleted, as on Cloud.

The "not supported" branch in everos-mcp's forget_session can stay for servers that predate the route.

Refs: EverOS-MCP src/everos_mcp/conversation.py::delete_all, src/everos_mcp/client.py::delete_session, src/everos_mcp/server.py::forget_session.

Lingua principale
Python
Stelle
13.3k
Fork
926
Merge medio
22h 56m
PR unite (30g)
27

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di EverMind-AI/EverOS

Tutte le issue di EverMind-AI/EverOS

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.