Summary
Spun out of #114 (the last unaddressed item in that robustness cluster; the other five are fixed in offload-v1 and #114 is closed).
The offload durability gate weighs only version-vector staleness — a component is "stale" when its covered origin run is below the file's origin run (offload/gate.go, the stale: have N need M path). It does not consider time-based staleness: a destination_run_ids row's updated_at_ns is ignored, so durability evidence never expires.
Why it matters
- Evidence for a destination that has been dead/unreachable for a long time still gates
offload indefinitely — the laptop will keep deleting local bytes on the strength of a "durable" claim that hasn't been re-confirmed in months.
- An equal-value re-advance refreshes
updated_at_ns without any re-verification, so a timestamp doesn't currently imply "recently checked" either.
This is defence-in-depth, not a live data-loss path (the gate is correct about coverage; it just has no notion of freshness in wall-clock time). It pairs naturally with the periodic re-verification story (squirrel verify, scrub).
What to decide / build
- Whether the gate should refuse (or warn on) a component whose
updated_at_ns is older than a configurable max age, per destination or globally.
- Whether an equal-value re-advance should not bump
updated_at_ns (so the timestamp tracks genuine re-verification, not no-op touches), or whether to add a separate verified_at_ns distinct from updated_at_ns.
- How this interacts with relayed (peer-pulled) evidence, which carries the peer's notion of freshness.
Where
offload/gate.go — gate evaluation (currently coverage-only).store/destination_run_ids.go — updated_at_ns semantics on advance / re-advance.
Originally item 6 ("No durability-evidence staleness policy") of #114; the other five items (run-gate symmetry, FinishHookRun guard, blake3 silent-degrade, config↔DB path check, kopia --init gate) are fixed in offload-v1.
Summary
Spun out of #114 (the last unaddressed item in that robustness cluster; the other five are fixed in
offload-v1and #114 is closed).The offload durability gate weighs only version-vector staleness — a component is "stale" when its covered origin run is below the file's origin run (
offload/gate.go, thestale: have N need Mpath). It does not consider time-based staleness: adestination_run_idsrow'supdated_at_nsis ignored, so durability evidence never expires.Why it matters
offloadindefinitely — the laptop will keep deleting local bytes on the strength of a "durable" claim that hasn't been re-confirmed in months.updated_at_nswithout any re-verification, so a timestamp doesn't currently imply "recently checked" either.This is defence-in-depth, not a live data-loss path (the gate is correct about coverage; it just has no notion of freshness in wall-clock time). It pairs naturally with the periodic re-verification story (
squirrel verify, scrub).What to decide / build
updated_at_nsis older than a configurable max age, per destination or globally.updated_at_ns(so the timestamp tracks genuine re-verification, not no-op touches), or whether to add a separateverified_at_nsdistinct fromupdated_at_ns.Where
offload/gate.go— gate evaluation (currently coverage-only).store/destination_run_ids.go—updated_at_nssemantics on advance / re-advance.Originally item 6 ("No durability-evidence staleness policy") of #114; the other five items (run-gate symmetry, FinishHookRun guard, blake3 silent-degrade, config↔DB path check, kopia
--initgate) are fixed inoffload-v1.