hub v0.60.1: host deletion demotes escrow custody (never destroys) + customer-delete purge point + S6b obsolete

- DeleteHost(deleteEscrow) demotes current host_escrow into host_escrow_superseded (copy-before-delete, same tx), spares existing; one shared demoteCurrentEscrowTx (reused by SaveHostEscrow). F-14 provenance/gate unchanged.
- DeleteCustomerConfig now purges both escrow tables for all the customer's hosts incl. already-deleted (F-14 provenance UNION) — the one true purge point.
- Wording: checkbox/refusal/Danger-zone → demotion. S6b OBSOLETE. Red-proofs TestDeleteHost_Demotes + TestDeleteCustomer_Purges + wording guard.
This commit is contained in:
2026-07-17 11:25:38 +02:00
parent 106c3379b0
commit 2752e12acc
12 changed files with 310 additions and 59 deletions
+30
View File
@@ -1,5 +1,35 @@
# Felhom Hub — Changelog
## v0.60.1 — host deletion DEMOTES escrow custody (never destroys) + S6b obsolete (2026-07-17)
Closes the deletion-path gap in v0.60.0's review: `DeleteHost(deleteEscrow=true)` was still DELETING
escrow rows (the same-customer reinstall flow funnels the operator straight into that tick).
Principle (Viktor's standing ruling): host deletion is a lifecycle event — blob custody survives it;
the customer Danger-zone Delete is the one true purge point. Green:
`go build ./... && go vet ./... && go test ./...`.
- **Scenario A — host delete demotes, never destroys.** `DeleteHost(deleteEscrow=true)` now DEMOTES
the current `host_escrow` row into `host_escrow_superseded` (copy-BEFORE-delete, same tx) and SPARES
existing superseded rows — no operator path through host lifecycle can lose a blob. Reuses THE one
escrow row-copy routine (`demoteCurrentEscrowTx`, also used by `SaveHostEscrow`). The F-14
provenance row + gate semantics are unchanged (wording updated: demotion, not destruction). Edge:
no escrow row → unchanged; the `ErrHostEscrowPresent` refusal without the flag is unchanged.
Red-proof `TestDeleteHost_DemotesEscrowNeverDestroys`.
- **Scenario B — customer delete is the purge point.** `DeleteCustomerConfig` (which previously deleted
ONLY the `customer_configs` row) now, in one tx, purges `host_escrow` AND `host_escrow_superseded`
for all the customer's hosts — INCLUDING already-deleted hosts (resolved via the F-14
`host_deletions` provenance) so a host-delete-then-customer-delete ordering leaves nothing orphaned.
Danger-zone copy states it. Red-proof `TestDeleteCustomer_PurgesEscrowCustody`.
- **Scenario C — wording.** The host-delete escrow checkbox now reads "Move key escrow to retained
custody (required when escrow present)…"; the refusal message + customer Danger-zone copy match.
Guard test `TestHostDeleteEscrowLabel_DemotionWording`.
- **Scenario D — S6b verdict (docs): OBSOLETE.** Re-enrolling an existing host_id upserts cleanly
(`UpsertHost` ON CONFLICT DO UPDATE, `store.go`; `handleAdminCreateHost` has no duplicate refusal) +
the v0.57.0 re-enroll arc auto-fires the re-issues → no manual stale-host deletion needed before
re-enroll. Scenario A also makes the funnel harmless either way. ROADMAP R-3 refined.
- **Scope:** hub-only; no controller/agent change; ACK assembly + upload supersede path untouched.
Deploy: bump `manifests/hub.yaml` tag to `0.60.1` and sync.
## v0.60.0 — offsite continuity Part B: superseded-escrow retention (data-first) (2026-07-17)
Closes the data-loss half of the reinstall-orphaned-repo incident: `SaveHostEscrow`'s destructive