chadtmiller.com/knotless
git that lives in your Atmosphere account
A push is one sync of its mirrors, not one for each record it wrote
MergedThis makes knotless-serve count one touch per commit rev instead of one per Jetstream event, so a push's pack, claim and ref cause one sync instead of two. I found nothing that must change.
- The rev is recorded only for events that write to the repository collections. A pull-state-only event therefore can't mask a later ref event in the same commit, as the description says.
- Events with no rev always count.
- The map holds one string per DID, so it stays small.
- The unit test covers the cases that matter. The design doc is updated to match.
I did not check the CI results or measure the sync pairs after deploy. The description already names that post-deploy check.
Since my last review, the pull has gained a merge of main and a commit that fixes the flaky mirror::tests::locks and the tidy test. The fix is sound. The free lock is now taken on a file nothing has opened, and the tidy test waits for its lock with Lock::acquire instead of asserting it is free. That removes the forked-fd race the description explains. The sync change is unchanged from the version I approved, and I found nothing new that needs to change. I did not look at CI results.
8 passed, 2 skipped
What changes
knotless-serve now counts a commit, not each of its records, toward a mirror going stale. Jetstream sends each record a commit wrote as an event of its own, and a push writes its pack, claim and ref in one commit. Only the first of those events, by the commit's
rev, marks the account's mirrors stale and syncs them. Only events that write to the storage collections record a rev. So a commit that also writes a pull's state, as a merge does, still syncs from its ref.Why
The new
mirror syncline shows that syncs of chadtmiller.com/knotless come in pairs about 1.3s apart (18:43:07/08, 18:44:30/31, 18:48:32/33), each about 1.25s. The first event of a push starts a sync. The rest arrive while it runs and leave it stale the moment it ends, so a second sync follows. Every read of the repository waits for both. The commit is atomic, so its records are already on the PDS when its first event arrives, and the first sync reads them all. Counting commits drops the second sync without a timer.How it was checked
A unit test,
one_commit_is_one_touch, covers it: the first event of a commit counts, the rest don't, other accounts and later commits count, and an event naming no commit always counts. The serve tests that follow a feed run in CI. After deploy, the check is whethermirror synclines for chadtmiller.com/knotless still come in pairs a push apart.Shortcomings
Each sync still reads every ref record, the deleted branches' included, about 1.25s for this repository. Reading only what a commit changed comes next. A push split over several
applyWritescalls (only a very large one) is several commits, and still several syncs.It also fixes the flaky
mirror::tests::locks, which failed this pull's first pre-flight. A flock belongs to the open file description, so a process forked by another test briefly holds a copy of the fd until it execs. A lock that was just let go can therefore still read as held. The test now takes its free lock on a file nothing has opened, and the tidy test waits for its lock instead of asserting it is free.Changeset: none
🤖 Generated with Claude Code