coulomb/prj-state-hub-retirement
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

T07: reuse-surface escalated — live federation dependency, not just a stale image

Browse source 
At the deployed commit, registry/federation/sources.yaml points at
gitea.coulomb.social for 50 of 61 sources; all 61 are forgejo at HEAD after
d1c1313. Production is actively federating from the host being switched off, so
it breaks on 2026-08-31 with no restart required — a different and worse failure
mode than the ImagePullBackOff risk it was first filed under.

This also inverts the conservative option: rebuilding the pinned commit onto
forgejo does not fix federation, because the gitea URLs are in the code at that
commit. Deploying HEAD is the smaller intervention once the runtime dependency is
counted.

Side finding routed to the repo: REUSE-WP-0019 is archived as finished and
records a production deploy of T01/T02, but T04-T06 — including hub freshness
monitoring — landed after the deployed commit and appear never to have shipped.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
tegwick 2026-08-20 22:37:19 +02:00
parent 65a6eafa06
commit 669a98ce1c
1 changed files with 23 additions and 5 deletions
Download patch file Download diff file Expand all files Collapse all files

28
workplans/SHR-WP-0002-predecessor-and-deployment-reality.md
View file

@ -255,11 +255,29 @@ images. It breaks at the next restart, reschedule or scale-up, as
**The two are not equally urgent** (corrected 2026-08-20 after checking each
reference's liveness):
- **`reuse-surface` — live and stale.** A running Deployment on the old
registry, pinned to a 2026-07-07 commit and **22 commits behind** main. Its CI
switched to forgejo three hours after that commit and has published there ever
since; the deployment was never repointed. **This is the one that must move
before 2026-08-31.**
- **`reuse-surface` — worse than stale: a live runtime dependency.** A running
Deployment on the old registry, pinned to a 2026-07-07 commit and **22 commits
behind** main. Its CI switched to forgejo three hours after that commit and has
published there ever since; the deployment was never repointed.
**Escalated 2026-08-20.** At the deployed commit,
`registry/federation/sources.yaml` points at `gitea.coulomb.social` for **50 of
its 61 sources** (all 61 are forgejo at HEAD — migrated in `d1c1313`,
`RAIL-HO-WP-0006`). So production is not merely running an old image: it is
**actively federating from the host being switched off**, and that breaks *on
2026-08-31 with no restart required*. This is a different and worse failure
mode than the `ImagePullBackOff` risk it was first filed under.
It also inverts the conservative option. Rebuilding the pinned commit onto
forgejo — the apparently low-risk choice — does **not** fix federation, because
the gitea URLs are in the code at that commit. Deploying HEAD is the smaller
intervention once the runtime dependency is counted.
Side finding for that repo: `REUSE-WP-0019` is archived as finished and records
a production deploy of its T01/T02 work, but T04–T06 (telemetry store,
aggregation, **hub freshness monitoring**) landed after the deployed commit and
appear never to have shipped. A workplan closed as done contains a
freshness-monitoring feature production does not have.
- **`state-hub` — mostly a false alarm.** The Deployment is already on
`forgejo.coulomb.social/coulomb/state-hub:main-d8808bf`. The gitea reference is
a *completed* one-shot Job that will not re-run by itself; the residual risk is