amadan
Box partitioned across the whole trash→purge span can keep serving a purged app's hand-added route Issue open
Migrated from github.com/carlosframework/platform issue #116, opened 2026-08-08. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".
Still outstanding: A box partitioned across the whole trash-to-purge span can serve a purged app's hand-added route forever.
---
Found reviewing the trash-serial-bump change. The fleet-visible teardown of a trashed app is marker-driven: domains.Reconcile drops every route of a trashed (account, app) while the trash marker exists, and provision.Reconcile declines minting. Purge (release.PurgeApp) then deletes the whole apps/<acct>/<app>/ prefix — marker included, last.
A box that is down or partitioned for the entire trash→purge window comes back to a bucket with no marker: leg 1c never sees the app as trashed, so only Provisioned routes get retired via record-gone removal. A hand-added (carlos add, non-Provisioned) route for the purged app keeps serving forever — the app is permanently deleted, the name may even be re-registered by someone else, and the stale box still routes the old binary.
A serial bump at purge time would not fix it (the returning box replays no history; it converges against current bucket state). Directions: a tombstone that outlives the purge for some window; or route-record reconciliation that treats "app prefix entirely absent" as retire-eligible for non-Provisioned routes too (careful: that must not retire routes for apps that simply predate instance records).
Low likelihood (requires a multi-day partition spanning trash→purge and a hand-added route), but the failure is permanent and invisible.
🤖 Generated with Claude Code