Skip to main content

Module tombstone

Module tombstone 

Source
Expand description

Tombstone semantics shared by every Store implementation (ADR 0021). Stores read the current record inside their own OCC critical section, ask a planner here what to do, and carry out the returned plan, so every substrate reaches identical decisions by construction.

Enums§

DeletePlan
What a store must do for a delete.
PurgePlan
What a store must do for a purge.
PutPlan
What a store must do for a put. Decided with the store’s current record in hand, inside its OCC critical section.

Constants§

CONSUMER_TOMBSTONE_REJECTED
The reason a consumer put of a RecordKind::Tombstone record is rejected (see PutPlan::Rejected).
DEFAULT_ANCESTOR_CAP
Ancestor list length used when a store is not configured otherwise. About 90 bytes per serialized entry: ~2.9 KB at the cap.
MANIFEST_TOMBSTONE_RECREATE_REJECTED
The reason a consumer put that would create over a manifest tombstone is rejected (see PutPlan::Rejected). A manifest tombstone retains the deleted body, which is the restore window ADR 0029 promises; overwriting it would unpin blobs that may be unregenerable (ADR 0030).
TOMBSTONE_DOMAIN
Domain string hashed to form every tombstone’s revision hash. Not the empty body’s hash: that would let a tombstone collide with a live record edited to an empty body at the same counter, and sync would miss the divergence.

Functions§

fold_ancestors
The ancestor list to persist for a record whose revision is stored, replacing current (if any), given the ancestors the writer supplied.
now_ms
Wall-clock milliseconds since the Unix epoch. A clock set before the epoch yields i64::MAX: collection treats a future stamp as too young, so a broken clock can only delay purging a tombstone, never make it early (spec §3.8).
plan_delete
Decide a conditional delete (spec §3.2). Deleting an absent key writes nothing: there is no revision to order a tombstone against a peer’s copy. Deleting a tombstone writes nothing: the chain does not advance.
plan_purge
Decide a purge: remove only the exact revision named, so a key recreated after its tombstone was listed survives collection.
plan_put
Decide a consumer put (spec §3.2). A RecordKind::Tombstone record is always Rejected: deletes go through Store::delete_as, and replication writes tombstones through put_raw. Otherwise, a tombstone counts as absent: a create (expected == None) recreates the key past the tombstone, and any Some(_) is NotFound. The one exception is a manifest tombstone (deleted_kind of GraphManifest or VectorManifest), whose retained body is a restore window: a create over it is Rejected with MANIFEST_TOMBSTONE_RECREATE_REJECTED. Replication writes use plan_put_raw.
plan_put_raw
Decide a replication write (Store::put_raw, spec §3.2). Never re-stamps: a tombstone is an ordinary record here. A create that finds anything stored (live or tombstone) is a Conflict carrying it, so sync re-reads instead of turning a copy into a recreation that would resurrect a deleted record.
reconciled_ancestors
Ancestors for a record that reconciles two diverged records a and b: a sync or pull merge result, or a tombstone winner. Both revisions and both ancestor lists are folded (spec §3.4), minus stored, sorted by (counter desc, hash desc) and truncated to cap.
reconciled_record
The record reconciling two diverged live records a and b into merged body (spec §3.4, §3.5): revision max(counter) + 1 over body, parent = the higher-counter side, labels and links unioned, both chains folded. On a label-key collision b wins, and on a counter tie the parent is a. Sync calls this with (a, b); pull calls it with (local, remote).
tombstone_hash
The revision hash shared by every tombstone.
tombstone_of
The tombstone that deleting the live record current produces. author, when given, is the deleter and replaces meta.author; otherwise the tombstone keeps the last live writer’s metadata.
tombstone_winner
Resolve two diverged tombstones for one key (spec §3.4, §3.5): the one with the higher (counter, hash) wins and carries ancestors reconciled from both.
validate_ancestor_cap
Reject an ancestor cap of zero: with no ancestors, sync could never fast-forward and every divergence would surface as a conflict.