Federated via graft
0

Configure Feed

Select the types of activity you want to include in your feed.

Fix: the approved column silently unapproved every pre-existing peer

The migration adding dynamic_repo.approved defaulted every row to 0,
including rows that were already materialized (live) under the old
model — federation-x-f3 among them. AllDynamicRepos now filters on
approved=1, so on the very next restart after this deploy, f3 silently
dropped out of live.syncers entirely: no error, no log line, just gone.
Caught live: its README stayed stuck for ~35 minutes across a restart
while f1/f2/bimr kept moving, and it sat invisible in /admin/pending
(a peer that had been live for hours suddenly asking to be
"re-approved" is exactly the tell).

Fixed with a startup backfill — UPDATE dynamic_repo SET approved = 1
WHERE materialized = 1 AND approved = 0 — idempotent (materialized
never reverts to 0), so safe to run unconditionally every startup, not
gated on "is this the first run after the column was added." Verified
with a test that closes and reopens a store with a pre-existing
materialized row and confirms it survives migration approved; verified
live: f3 reloaded on restart, dropped out of the pending queue, and
resumed picking up new commits.

Also: dropped the Radicle-side sentence from /add-peer's lead
paragraph (redundant with the field-level hint already there).

+11 -1
+1 -1
internal/admin/onboard.go
··· 20 20 21 21 var addPeerTmpl = template.Must(template.New("add-peer").Parse(` 22 22 <h1>Add a peer to an existing federation</h1> 23 - <p class="lead">Joins a Forgejo instance to a repo already mirrored elsewhere. Radicle side (RID, node, explorer) is inherited from the chosen series.</p> 23 + <p class="lead">Joins a Forgejo instance to a repo already mirrored elsewhere.</p> 24 24 {{if .Error}}<div class="notice bad">{{.Error}}</div>{{end}} 25 25 <div class="card"> 26 26 <form method="POST" action="/add-peer">
+10
internal/state/store.go
··· 216 216 return err 217 217 } 218 218 } 219 + // Backfill: a dynamic_repo row that was already materialized before 220 + // the approved column existed was live and trusted under the old 221 + // model — the ALTER above defaults it to approved=0 along with every 222 + // other row, which would silently pull an already-active peer back 223 + // out of the sync loop on the next restart. Idempotent (materialized 224 + // never reverts to 0), so safe to run unconditionally every startup, 225 + // not just the first one after the column was added. 226 + if _, err := db.Exec(`UPDATE dynamic_repo SET approved = 1 WHERE materialized = 1 AND approved = 0`); err != nil { 227 + return err 228 + } 219 229 return nil 220 230 } 221 231