Add Radicle peer onboarding; fix dynamic peers vanishing on restart
New /add-radicle-peer: connects a new Radicle node to the mesh and
seeds an existing federation's RID (rad node connect + rad seed on
graft's own node), gated by the same admin password + rate limiter as
the Forgejo onboarding forms. No DB row needed — it's a one-time
operational action, not an ongoing sync pair. Cross-linked with
/add-peer; dashboard gets a third button.
Fixes a real bug caught live: federation-x-f3 (added via /add-peer
earlier) silently dropped out of the sync loop on every graft restart
since then — main() only rebuilt live RepoSyncers for dynamic_repo rows
still unmaterialized, never for ones a previous run had already
materialized, so a dynamic peer's syncer simply ceased to exist after
any deploy. Confirmed via f3's README staying stale for ~50 minutes
across several restarts while f2/bimr updated normally. Fixed with
loadAllDynamicRepos, called once at startup regardless of the
materialized flag — deliberately non-fatal on a load failure (unlike a
bad static config.yaml pair), since the self-service path exists
specifically to tolerate transient failures, not turn one peer's
hiccup into a full outage. Verified live: f3 reloaded on restart,
caught up on a real README change within one sync pass.
Also: dropped three redundant/stale sentences from the onboarding page
copy (a leftover "not entered here" clause, a since-superseded
auto-init warning now covered by the Adding-a-peer docs instead, and a
"no restart" hint repeated between the form and its own success page),
and "Pair name" -> "Peer name" for consistency with the rest of the UI.
Add Radicle peer onboarding; fix dynamic peers vanishing on restart
New /add-radicle-peer: connects a new Radicle node to the mesh and
seeds an existing federation's RID (rad node connect + rad seed on
graft's own node), gated by the same admin password + rate limiter as
the Forgejo onboarding forms. No DB row needed — it's a one-time
operational action, not an ongoing sync pair. Cross-linked with
/add-peer; dashboard gets a third button.
Fixes a real bug caught live: federation-x-f3 (added via /add-peer
earlier) silently dropped out of the sync loop on every graft restart
since then — main() only rebuilt live RepoSyncers for dynamic_repo rows
still unmaterialized, never for ones a previous run had already
materialized, so a dynamic peer's syncer simply ceased to exist after
any deploy. Confirmed via f3's README staying stale for ~50 minutes
across several restarts while f2/bimr updated normally. Fixed with
loadAllDynamicRepos, called once at startup regardless of the
materialized flag — deliberately non-fatal on a load failure (unlike a
bad static config.yaml pair), since the self-service path exists
specifically to tolerate transient failures, not turn one peer's
hiccup into a full outage. Verified live: f3 reloaded on restart,
caught up on a real README change within one sync pass.
Also: dropped three redundant/stale sentences from the onboarding page
copy (a leftover "not entered here" clause, a since-superseded
auto-init warning now covered by the Adding-a-peer docs instead, and a
"no restart" hint repeated between the form and its own success page),
and "Pair name" -> "Peer name" for consistency with the rest of the UI.
Add Radicle peer onboarding; fix dynamic peers vanishing on restart
New /add-radicle-peer: connects a new Radicle node to the mesh and
seeds an existing federation's RID (rad node connect + rad seed on
graft's own node), gated by the same admin password + rate limiter as
the Forgejo onboarding forms. No DB row needed — it's a one-time
operational action, not an ongoing sync pair. Cross-linked with
/add-peer; dashboard gets a third button.
Fixes a real bug caught live: federation-x-f3 (added via /add-peer
earlier) silently dropped out of the sync loop on every graft restart
since then — main() only rebuilt live RepoSyncers for dynamic_repo rows
still unmaterialized, never for ones a previous run had already
materialized, so a dynamic peer's syncer simply ceased to exist after
any deploy. Confirmed via f3's README staying stale for ~50 minutes
across several restarts while f2/bimr updated normally. Fixed with
loadAllDynamicRepos, called once at startup regardless of the
materialized flag — deliberately non-fatal on a load failure (unlike a
bad static config.yaml pair), since the self-service path exists
specifically to tolerate transient failures, not turn one peer's
hiccup into a full outage. Verified live: f3 reloaded on restart,
caught up on a real README change within one sync pass.
Also: dropped three redundant/stale sentences from the onboarding page
copy (a leftover "not entered here" clause, a since-superseded
auto-init warning now covered by the Adding-a-peer docs instead, and a
"no restart" hint repeated between the form and its own success page),
and "Pair name" -> "Peer name" for consistency with the rest of the UI.