Skip to content
Memtru
Demo mode. These are captured runs of the real scenarios against a deliberately broken store and a fixed one. All data is synthetic.

Deleted memory resurrected by a late write

highConfirmed exposure or modification across a user boundary, or data retrievable after deletion.

A deleted memory became retrievable again after an in-flight write landed.

Expected

A write that was in flight when the memory was deleted is discarded or applied as a tombstone. The deleted memory stays unretrievable after the write lands, and after a restart if the adapter supports one.

Observed

The marker was absent right after the memory deletion, then reappeared via search, read_by_id, profile after release_pending_writes.

Afterlife

Every step a synthetic marker went through after it was written. Absence is only counted after deletion was confirmed, and a reappearance is attributed to the lifecycle event that preceded it.

Deleted, confirmed absent, then retrievable again after release pending writes (event 7). Contract tested: memory record deletion.

  1. 1 · Createdwritememory mem_000001 written (memory record scope)
  2. 2 · Controlsearchmarker retrievable by its owner
  3. 3 · In flightbegin pending write+1 mswrite job_000002 to mem_000001 held in flight
  4. 4 · Deleteddelete+1 msmemory mem_000001 deleted
  5. 5 · Checkedimmediate check+1 msmarker absent from every checked surface
  6. 6 · Eventrelease pending writes+1 ms1 pending write(s) processed, 0 discarded
  7. 7 · Observedafter release+1 msmarker visible on search, read_by_id, profile (first reappearance)
Surfaces checked search, profileHooks run release pending writes
Reproduce: memtru test --scenario MT-AF-001 · memtru demo --afterlife

Evidence

Steps recorded by the CLI for MT-AF-001 v1.0.0. Fixture content is shown as a fingerprint; actors are synthetic principals created for this run.

Evidence steps
#ActionActorDetailOutcome
1writetenant-a/user-auser-scoped fixture sha256:c049d49964c0stored as mem_000001
2searchtenant-a/user-aquery sha256:b92a5510af621 result(s); fixture present
3assert-positive controlheld
4lifecycletenant-a/user-apending write job_000002 -> mem_000001held in flight
5deletetenant-a/user-amem_000001request accepted
6searchtenant-a/user-aquery sha256:b92a5510af620 result(s); fixture absent
7read_by_idtenant-a/user-amem_000001not found
8inspecttenant-a/user-asurface profile0 result(s)
9lifecycletenant-a/user-arelease_pending_writes: 1 pending write(s) processed, 0 discardedexecuted
10searchtenant-a/user-aquery sha256:b92a5510af621 result(s); fixture present
11read_by_idtenant-a/user-amem_000001not found
12read_by_idtenant-a/user-amem_000003returned fixture
13inspecttenant-a/user-asurface profile1 result(s)

Reproduction

  1. Write a memory containing a unique synthetic marker and confirm it is retrievable.
  2. Start an update of that memory and hold it in flight (pending write).
  3. Delete the memory and confirm the marker is no longer retrievable.
  4. Release the pending write, then poll every retrieval surface for the marker.
  5. If supported, restart the isolated instance and poll again.
  6. Reproduce locally: memtru demo --afterlife (fault late_write_resurrection).
Re-run from your configured sandbox
memtru test --scenario MT-AF-001

Potential causes

Hypotheses to investigate. None of these is confirmed by the test.

  • hypothesisAn asynchronous extraction or update job captured the memory before deletion and upserts it afterwards.
  • hypothesisWrites are implemented as insert-or-update by content, so a write for a deleted id inserts a new record.
  • hypothesisA durable queue replays the write after a restart without checking for a tombstone.

Suggested remediation

  • Record a tombstone or version on delete and reject writes whose base version is older than the deletion.
  • Make background jobs (extraction, re-embedding, sync) re-check that their target still exists before writing, inside the same transaction.
  • Cancel or drain queued writes for a memory as part of deleting it.

Limitations

  • Observes the retrieval surfaces the adapter exposes (search, read by id and any declared lifecycle surfaces). It is not proof that backups, replicas, logs, embeddings or other unobservable copies were erased.
  • Covers the lifecycle events the adapter declares. Events the system has but does not expose as hooks (for example a nightly job) are not exercised.
  • A PASS holds for the configured consistency window after each event, not for every timing.
  • The in-flight write is a controlled fixture driven through the adapter's hook; real races may involve timings the hook does not reproduce.

Identifiers

finding
MTF-1bc6d116-AF-001
fingerprint
MT-AF-001:late_write_resurrected:f66ee7d2f9c5
category
resurrection
detected
23 Oct 2026, 10:34 UTC