jerry/buzz

mirror of https://github.com/block/buzz.git synced 2026-11-01 23:11:58 +00:00

Files

npub1mn7jgtj4w2pd0g0zeuhxsa6jy6p0rewxz4kujt98my82ahfmp72sxjexk7 cf30ff47d3 fix(desktop): gate agent config publishes behind a boot resolution pass

Boot reconcile re-signs whatever is on disk at `monotonic_created_at =
max(now, head + 1)`, so a merely-stale store mints events strictly newer
than the edits they revert. Last-write-wins then adopts the revert. A
second install with a fresh retention database is exactly this state,
which is why a dev build silently reverts config edited elsewhere.

`created_at` cannot arbitrate it: the value the stale store carries is
manufactured by the reconcile, not observed. The barrier arbitrates on
PROVENANCE instead. A baseline records what this install last agreed was
published at a coordinate; with no baseline, the install cannot show it
ever agreed to anything there, so neither its content nor its timestamps
are evidence of intent about the relay's state.

`decide` runs four ordered gates: positive tombstone evidence, then the
no-baseline park, then the queued-deletion timestamp compare, then the
queued edit against the baseline. The ordering is load-bearing — the
timestamp compare is sound only because the no-baseline gate already
excluded every store that would win it spuriously.

Both publication gates are enforced, because a coordinate's record and
its queued tombstone occupy different primary keys and the flush loop
reads them independently: gating one row computes a suppression and
enforces half of it. The live gate is default-deny over the decision
set, so a variant added later is withheld until deliberately admitted.

The scan is per-owner and unfiltered by `#a` because the relay
post-filters `#a` after its `LIMIT`, so absence is claimed only from a
page shorter than the limit it asked for.

Nothing is applied to disk here. `ApplyHead`, `RestoreFromRelay`, and
`DeleteLocal` are decided, logged, and gated; resolving them is the
user-driven step.

On relay deployments with a replica-routed read pool, the head lookups
and tombstone scan read best-available rather than writer-consistent;
staleness within replication lag is a documented known limitation (see
`head_lookup` and `tombstone_scan` module docs). The barrier's
per-decision tracing line is the detection mechanism if it fires.

Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>

2026-08-01 14:09:31 -04:00