chadtmiller.com/knotless

Switch repository

Loading…

What changes

A private repository's space that its authority said is deleted, or has no such space, is remembered in the index (space_gone), and the owner's spaces found as they log in or look at their profile skip it. Following the space for any other reason, as a member reading it or its authority telling of a write there, clears that, since a deleted space can be made again at the same URI. Only SpaceDeleted and SpaceNotFound mark it: a syncer no longer a member (UserNotAuthorized) says nothing of the space, and must not hide an owner's repository from their own profile.

Why

The owner's PDS goes on naming deleted spaces in listSpaces. So every look at the owner's profile followed all five again (invite-test, opensocial, private-runner-test, private-test, supsup), synced each only to be refused SpaceDeleted, and the next sweep forgot them: 170 space not synced warnings in the last 14 hours on prod, and as many wasted credential round trips.

How it was checked

private_repositories_heard_of goes on past the deletion: told of a write in the deleted space, the server follows it again, is refused, and remembers it gone and unfollowed. The rest is left to CI. On prod, after it deploys, space not synced for these five should stop after one more round each.

Shortcomings

The reference PDS leaves deleted spaces out of listSpaces, so no test sees discovery skip one; the skip is a filter on what it lists. The table is a cache, dropped with the rest on a rebuild, which costs one failed sync of each again.

Changeset: none

🤖 Generated with Claude Code

This adds a space_gone table. A space whose sync is refused with SpaceDeleted or SpaceNotFound, or whose authority tells of its deletion, is recorded there. owned() then skips recorded spaces when it follows an owner's listSpaces. follow_space clears the record, so a space recreated at the same URI is followed again once its authority tells of a write there. The table is dropped with the rest of the cache and purged by owner prefix. The docs page is updated and the test extension covers the loop. I found no bugs.

I did not run the checks. The 100% coverage gate is the one to watch, because the skip filter in owned() has no test (as the body says).

One tradeoff to know about: an owner who recreates a space at the same URI won't see it picked up at login. It is only found when the authority tells of a write there. That fits the design and the docs.