@@ -297,7 +297,7 @@ function filterFlaggedDuplicates(memories, flaggedOnly) {
297297 return memories . filter ( ( m ) => Array . isArray ( m . metadata ?. possible_duplicate_of ) && m . metadata . possible_duplicate_of . length ) ;
298298}
299299
300- // REGRESSION FIX (2026-07-13, see manufact -mem0-relations-plan): the
300+ // REGRESSION FIX (2026-07-13, see madmcp -mem0-relations-plan): the
301301// /v3/memories/ list endpoint does not reliably surface metadata.relations
302302// contents, even though it does reliably surface metadata.entity_id (which
303303// is why entity_id matching below still works off list results directly).
@@ -374,7 +374,7 @@ async function findByEntityIdAnyScope({ user_id, entity_id }) {
374374// single direct lookup. Returns [{ fromEntityId, fromId, relation }, ...].
375375// Same ~1000-memory-per-scope pagination ceiling as findByEntityId.
376376//
377- // REGRESSION FIX (2026-07-13, see manufact -mem0-relations-plan and the note
377+ // REGRESSION FIX (2026-07-13, see madmcp -mem0-relations-plan and the note
378378// above findByEntityId): list-page results can't be trusted for
379379// metadata.relations, so every candidate in every page gets refetched via
380380// fetchSingleForMetadata (single-get) before its relations are inspected.
@@ -525,7 +525,7 @@ async function findPossibleDuplicates({ user_id, agent_id, run_id, content, thre
525525 return memories . filter ( ( m ) => typeof m . score === "number" && m . score >= threshold ) ;
526526}
527527
528- // NOTE on add-then-verify (2026-07-10, following manufact -mem0-add-silent-
528+ // NOTE on add-then-verify (2026-07-10, following madmcp -mem0-add-silent-
529529// failure-diagnostic): /v3/memories/add/ returning a 2xx with an event_id
530530// only means Mem0 ACCEPTED the job, not that its async extraction/indexing
531531// pipeline actually materialized the memory — that step has been observed
0 commit comments