Persist the relation-publication retry marker inside the accepted-write transaction

[phernandez]

Follow-up from basic-memory-cloud docs/MATERIALIZATION_WEBHOOK_PLAN.md (step C4), split out of basic-memory#1660.

Gap

After an accepted note write commits, _finish_mutation (services/note_content_writes.py:253-273) publishes the note's graph (observations, relations, sections). Before publishing, RelationRepository.begin_relation_generation_publication persists a RelationSearchRefresh.publication_generation retry marker, and cleanup_relation_generations clears it after success. While the marker exists, EntityRepository.get_by_file_paths masks entity.checksum, so the next storage notification or project index re-reads the note and republishes its graph. That is the repair path, and it survives basic-memory#1660.

The remaining hole: a crash or database error after the accepted write commits but before the retry marker is written leaves no marker. The graph stays unpublished, nothing masks the checksum, and once #1660 records the materialized object's storage checksum, the storage notification finds the note current and does not repair it. Today a graph-publication failure is only logged ("a later index pass can republish").

Proposed fix

Write the publication retry marker in the same transaction as the accepted write, so every committed accepted generation either has its graph published or carries a durable marker until it is.

Care needed

• This is in lock-ordering territory: the Remove SELECT FOR UPDATE from note materialization publish; rely on the db_version CAS with guarded writes #1224 deadlock class and the note_content-first order the materialization publisher relies on. Adding a RelationSearchRefresh insert to the accept transaction needs a PostgreSQL concurrency test, alongside test-int/test_note_materialization_lock_order.py, proving the order still holds.
• Confirm the marker is cleared by the in-request publish on the happy path, so the next notification is not masked unnecessarily (that would bring back the re-index this plan removes).

Not in scope

Lost embeddings: basic-memory-cloud now queues embeddings from the durable materialize_note_file job.

🤖 Generated with Claude Code

https://claude.ai/code/session_01T8wjd6HrtSA2LN9ssC4NzF

[claude]

Claude finished @phernandez's task in 15s —— View job

---

Triage

• Type: Bug. It's a durability gap: a crash or DB error after an accepted write commits, but before the retry marker is written, leaves the graph unpublished with no repair path.
• Component: Database/sync. This is the note write path, RelationSearchRefresh and EntityRepository.get_by_file_paths. It isn't Cloud-specific, but it is motivated by basic-memory#1660 and the cloud materialization plan.
• Priority: Medium. The window is narrow, and the derived graph state is eventually consistent by design. It becomes a real non-converging case once fix(core): compare storage and content checksums like with like; record the materialized object's storage checksum #1660 records the storage checksum, because then nothing masks the checksum and the notification path stops repairing.
• Complexity: Complex. The change touches lock-ordering territory (the Generation-versioned relation persistence: eliminate indexing deadlocks on the relation table #1213/Remove SELECT FOR UPDATE from note materialization publish; rely on the db_version CAS with guarded writes #1224 deadlock class and the NoteContent-first order). It needs a PostgreSQL concurrency test next to test-int/test_note_materialization_lock_order.py. It also needs a check that the in-request publish clears the marker on the happy path.
• Duplicates: None found (searched for "relation publication retry marker").

Triage only: I haven't made any code changes. The issue already states the proposed fix and its constraints clearly, so I have no clarifying questions.