Repository navigation
RivetUpdate: own the silent-check throttle stamp (three products, three write-time semantics) #251
Description
The family contract says a silent update check persists a ~4 h throttle stamp, but every host writes it at a different moment, so the same outage produces different behavior per platform:
- threadly macOS: stamps before the check (one offline launch = silent for 4 h, even though nothing was checked)
- threadly/taskly Windows: stamps even when the transport itself failed
- threadly/taskly Linux: stamps only when the check settles
- movebit backend: no persistent stamp at all (every launch checks 3 s in, then every 6 h in-process)
Proposal: RivetUpdate / the distribution updater-scaffolding (#240) owns the stamp: define "checked" as check settled (answer or definitive failure), persist it behind the product's settings interface, and expose should-silent-check?. Hosts stop hand-rolling timestamps in three languages.
Activity
turinglambdaai commentedon Oct 17, 2026
Fixed by #271 (merged): the updater scaffolding owns the silent-check throttle stamp with exactly the settle-then-stamp semantics this issue demanded —
silent-check-due?reads the stamp through the product's settings adapter,mark-silent-checked!writes it only when a check settles (an answer or a definitive failure; the fetch-failure test pins that an outage stamps exactly once instead of retry-storming), and the three per-platform hand-rolled timestamp semantics (threadly-macOS pre-check stamp, Windows stamp-on-transport-failure, movebit no-stamp) collapse into one tested implementation. The sticky rollout bucket (resolve-rollout-bucket!/draw-rollout-bucket) landed in the same merge, completing the settings-interface proposal of #240 as well. Products delete their hand-rolled timestamps as they rebase on the next rivet release.