DB-first note writes omit observations and relations until a later file re-index

[phernandez]

Summary

Cloud-hosted write_note calls can successfully persist typed Markdown and return 202 while leaving the observation and relation tables empty. Graph rows appear only if a later index_file job happens to re-parse the materialized object. This makes schema inference and relation traversal nondeterministic after successful DB-first writes.

Classification: Basic Memory persistence/indexing regression. The incomplete accepted-write path is in basic_memory.indexing.accepted_note_write_runner, not Cloud MCP routing.

Development acceptance evidence

Environment: Basic Memory Cloud development

• Cloud revision: 4aa58632c32999b088efcfe61911c053b7a4ad89
• Basic Memory revision: c616148fb0b30f1dfe492e273ec43706c0326759
• Tenant: a5a774be-50e0-4c50-811d-42a2525faebc
• Project external ID: d71bee1e-69a4-4842-90de-fd93aa779a47
• Project DB ID: 3

The acceptance run wrote three notes with note_type=dev_accept_person:

## Observations

- [name] Ada Acceptance
- [role] Engineer

## Relations

- works_at [[XSYS Target 20260716T1110Z]]

All three calls succeeded. note_content.markdown_content contains the exact [name], [role], and works_at Markdown, checksums match, and Tigris origin objects contain the same data. search_notes(note_types=["dev_accept_person"]) returns all three notes.

However, Neon shows no graph rows for entity IDs 13, 14, and 15:

• observation: zero rows
• relation: zero rows

schema_infer(note_type="dev_accept_person", threshold=0.25) therefore returns:

{"error":"No schema pattern found for 'dev_accept_person' (threshold: 25%)"}

A control note in the same project did acquire observations/relations, but only after Tigris notification enqueued index_file job trace 019f6aa0ae27f04fb3ea107af903cc84. The typed-note materialization jobs completed successfully but did not produce equivalent index_file jobs.

Root cause

run_accepted_note_create() prepares parsed Markdown, then create_accepted_pending_entity() writes only scalar entity fields. persist_accepted_note_write() writes note_content and search state. Neither persists the parsed observations or relations that are already present in the prepared write.

The Cloud DB-first path then materializes Tigris asynchronously. Graph correctness is accidentally dependent on a later object notification and index_file pass. Notifications are not a valid commit path for graph rows and may also no-op against matching accepted checksums.

Relevant code:

• src/basic_memory/indexing/accepted_note_mutation_runner.py::_run_accepted_note_create
• src/basic_memory/indexing/accepted_note_write_runner.py::create_accepted_pending_entity
• accepted update/edit paths should be audited for the same omission

Expected behavior

A successful accepted create/update/edit transaction atomically persists:

• entity scalar fields
• note content
• observations
• relations (with unresolved targets allowed)
• search state

Tigris materialization and object notifications should reconcile file state, not be required to make the knowledge graph correct.

Suggested fix

Extend the accepted mutation write transaction to replace observations and relations from the already parsed prepared Markdown before commit. Reuse the existing repository semantics used by EntityService.update_entity_and_observations() and update_entity_relations(), adapted to the accepted-write dependency protocols.

Add regression coverage for:

1. create typed note -> observations and unresolved/resolved relations exist immediately;
2. update/edit -> old graph rows are replaced atomically;
3. schema inference succeeds immediately after typed MCP writes without any storage notification;
4. relation traversal succeeds immediately after write_note;
5. materialization or duplicate index_file does not duplicate/remove graph rows;
6. missing/delayed Tigris notification does not affect DB graph correctness.

[claude]

Claude finished @phernandez's task in 20m 51s —— View job

---

Root cause confirmed and fix implemented

The bug is exactly where the issue points: run_accepted_note_create/_update/_edit in basic_memory/indexing/accepted_note_mutation_runner.py already parse observations/relations from the accepted markdown (prepared.entity_markdown), but the accepted-write path only ever persisted entity scalar fields (create_accepted_pending_entity), note_content, and search rows (persist_accepted_note_write) — observation/relation tables were never touched until a later index_file job happened to reparse the materialized file.

Todo List:

• Gather context: read issue body and referenced code paths
• Understand request: confirm this is a bug report + implementation request
• Investigate accepted_note_mutation_runner.py / accepted_note_write_runner.py for the accepted-write path
• Determine root cause and scope of fix
• Implement fix: persist observations/relations atomically in accepted create/update/edit paths
• Add regression tests
• Run lint/typecheck/tests (blocked — see note below)
• Push branch and provide PR link (blocked — see note below)
• Triage: labels, priority, component, complexity

What changed

• indexing/accepted_note_write_runner.py: extended the AcceptedPreparedMarkdownWriteSource protocol with observations/relations, added AcceptedNoteObservationRepository/AcceptedNoteRelationRepository capabilities to AcceptedNoteWriteRepositories, and added replace_accepted_note_graph() which replaces an entity's full observation/relation set atomically. Relation targets are written unresolved (to_id=None); the existing forward-reference resolution job reconciles them later, matching cloud's one-file materialization semantics — no new link-resolution logic needed.
• indexing/accepted_note_mutation_runner.py: wired replace_accepted_note_graph() into _run_accepted_note_create, _run_accepted_note_update, and _run_accepted_note_edit, right alongside the existing persist_accepted_note_write() call, in the same transaction.
• repository/observation_repository.py / repository/relation_repository.py: added replace_accepted_observations() / replace_accepted_outgoing_relations() (delete-then-insert, matching the replace-not-merge semantics EntityService.update_entity_and_observations/update_entity_relations already use for the local file-indexing path), plus AcceptedObservationWrite/AcceptedRelationWrite write payloads.
• services/entity_service.py: PreparedEntityWrite now exposes .observations/.relations (delegating to the already-parsed entity_markdown) so the accepted-write path can reuse it without reparsing.
• index/local_notes.py: wired the new repository methods into LocalAcceptedNoteRepositories (the local-runtime implementation of the write-repository protocol).

Regression coverage added

• tests/repository/test_observation_repository.py, test_relation_repository.py: replace_accepted_observations/replace_accepted_outgoing_relations insert the full set, replace an existing set atomically, and clear rows when the new set is empty; relations are asserted unresolved (to_id is None).
• tests/indexing/test_accepted_note_write_runner.py: unit tests for the new mapping helpers and replace_accepted_note_graph().
• tests/indexing/test_accepted_note_mutation_runner.py: end-to-end orchestration tests proving create persists observations+relations immediately, update replaces the graph atomically, and edit clears graph rows when the markdown drops them — directly covering issue items 1 and 2.
• Schema-inference/relation-traversal-after-write and materialization/duplicate-index_file idempotency (issue items 3–6) aren't independently covered by new tests — they exercise services outside this runner's unit-test boundary, and the DB-cascade-on-delete/replace-not-merge semantics this fix reuses are already relied on by the existing file-indexing path.

⚠️ Two things I could not complete in this environment

1. Could not run just fast-check / just fast-test / pytest. This sandbox's Bash permission mode rejected python3 -c, uv, just, and python3 -m pytest invocations ("this command requires approval") with no interactive user available to approve them. I reviewed every diff manually (imports, protocol conformance, line lengths, blank-line formatting) but could not execute the test suite. Please run just fast-check && just fast-test (or at least pytest tests/indexing/test_accepted_note_write_runner.py tests/indexing/test_accepted_note_mutation_runner.py tests/repository/test_observation_repository.py tests/repository/test_relation_repository.py tests/index/test_local_accepted_note_repositories.py) before merging. If you'd like me to fix this for future runs, updating --allowedTools to permit Bash(uv:*)/Bash(just:*) would let me self-verify.
2. Could not push the commit. git push failed with remote: Permission to basicmachines-co/basic-memory.git denied to github-actions[bot] (403). The commit exists locally on claude/issue-1076-20260716-1129 (SHA 20b69f1, signed off, on top of c616148) but the GitHub App token this session was given lacks write access to the repo. This needs a maintainer to either grant push access or re-run with valid credentials — I can't work around it from here.

Triage

• Type: Bug report — applied the bug label
• Priority: High — accepted (DB-first) writes silently produce incomplete graph state; schema inference and relation traversal are nondeterministic until an unrelated background job happens to run. (Couldn't apply a priority label — high/medium aren't in this repo's label set and I couldn't enumerate the actual set since gh label list was also blocked in this sandbox.)
• Component: Database/sync (indexing). (Couldn't apply a component label for the same reason — database/core/sync aren't recognized label names here.)
• Complexity: Medium — root cause and fix are contained to the accepted-write runner + two repositories, following patterns already established elsewhere in the codebase
• No duplicates found for this issue.