Skip to content

mdbase-next: route vault writes through the mdbase runtime when installed (seam, off by default) - #2385

Closed
callumalpass wants to merge 1 commit into
mainfrom
feat/mdbase-next-backend
Closed

callumalpass wants to merge 1 commit into
mainfrom
feat/mdbase-next-backend

Conversation

@callumalpass

Copy link
Copy Markdown
Owner

This is the first step of the TaskNotes port to mdbase-next. The obsidian workstream owns it. Please don't merge or release it yet; the coordinator handles that.

What it does. VaultMutationService is already TaskNotes' single write funnel (processFrontMatter, process, create, modify). This PR adds an installable MdbaseMutationBackend. When it's installed and claims a file (the file is in the mdbase collection and is a known record), writes become replica intents:

  • Frontmatter callbacks become a field-level update: the keys the callback set or removed, with the values it read as the merge base. Two devices editing different fields of one task both keep their change, instead of the last whole-file write winning.
  • Content callbacks and modify become a document replace, with the read document as the base. The replica merges, or holds on a real conflict.
  • create becomes a record create at the requested path.
  • Waiting: each call resolves once the write is published into the vault and indexed (settle), so callers that re-read the file afterwards behave as before. It doesn't wait for sync confirmation, so TaskNotes behaves the same offline.
  • Fallback: files outside the collection, and writes while no backend is installed, use Obsidian's APIs unchanged.
  • Renames still go through vault.rename. The replica observes them as moves.

Not installed by default. Nothing calls setMdbaseMutationBackend yet, so there's no behaviour change and no release-notes entry. Wiring it up follows in a later PR: attach to the shared runtime (@mdbase-dev/obsidian-runtime), and adapt @mdbase-dev/sdk's MdbaseClient to MdbaseWriteClient. That waits until runtime.wasm hosts the file store (mdbase-next #58, #103 and #134).

Checks run:

  • typecheck;
  • npm run lint (including architecture conformance);
  • jest tests/unit/core: 17 tests, 6 of them new. They cover field-level diffs, no-op suppression, document replace with base, modify/create routing, the fallback outside the collection, and behaviour without a backend.

No changes to .ops/.

… installed

VaultMutationService is TaskNotes' single write funnel. When an
MdbaseMutationBackend is installed and claims a file (it is in the mdbase
collection and is a known record), writes become replica intents:
frontmatter callbacks -> field-level updates (set/unset keys with the read
values as merge base), content callbacks and modify -> document replace with
the read document as base, create -> record create. Each call resolves once the
write is published into the vault, so callers see the same behaviour as with
Obsidian's APIs. Without a backend, or for files outside the collection,
nothing changes. Not installed by default yet: the shared runtime wiring
lands once runtime.wasm hosts the file store.
@callumalpass

Copy link
Copy Markdown
Owner Author

Superseded by #2386. Per Callum, the mdbase-next integration targets the v5 beta line (agent/tasknotes-v5-documentation), not main/4.13.x. #2386 carries this change plus the collection-metadata resource writes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant