Skip to main content

Module apply_commit

Module apply_commit 

Source
Expand description

Apply a CommitEnvelope to the in-memory store.

Distinct from the engine’s git-touching mutation paths (crate::engine::mutation): apply_external_commit materializes changes the engine did not author. The wire envelope arrives from some external producer (the bridge today; future Node / Python adapters) and replays the per-entity changes against the [Store] without producing a new commit. Routes:

  • WASM clients receive envelopes over the bridge wire and call this method to keep their in-memory mirror in step with the server.
  • Native test setups use it to seed a known graph state without running the full storage pipeline.
  • A future replay tool reads a stream of envelopes back from disk and reconstructs the graph at a point in history.

Per-change semantics:

  • Added / Modified → parse the new body, upsert into the store, re-emit explicit relationship edges. Parse failures abort the entire envelope (the post-state must be coherent — a partial apply would leave the store wedged between two SHAs).
  • Deleted → drop the entity and cascade its edges.
  • Renamed → drop the source entity, then parse + upsert the new body at the new id. We do not call [Store::rename_node] because the wire content is authoritative — the new body may carry a different relationship section than the old one did.

Schema-validation is soft: a parse failure refuses (the entity can’t be loaded at all), but schema-level warnings (dangling wiki-links, unknown rel-types in the relationships section) do not refuse — the server is the authority on schema, the client mirrors what arrives.

HEAD cursor + subscriber notification: after a successful apply the engine’s cached last_known_head for the affected mount advances to the envelope SHA, and one MemChangedEvent fires to every subscriber. Same shape every other mem-advance event flows through.