~ knotless Search/
↑↓ move↵ open⇧↵ all results

chadtmiller.com/knotless

git that lives in your Atmosphere account

knotless.dev
1 collaborator

knotless 0.13.0 Latest 2 packages, 1 image

1
10

A push is one sync of its mirrors, not one for each record it wrote

Merged
Merged chadtmiller.com asked to merge into main from chadtmiller.com/knotless:serve/one-sync-a-commit

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 sync line 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 whether mirror sync lines 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 applyWrites calls (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

Approved

This 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.

Approved

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.

Merged as f13a8b5