Repository navigation
Provider launches through headroom stay refused after a door turnover while old sessions are registered #367
Description
A provider launch routed through headroom is refused with "the running headroom daemon was started before this launch's front door address" for as long as any launch is registered against the daemon, and nothing ends that on its own.
The door's direct origin is on headroom's allowlist, and the list is fixed when the daemon starts. When the door's direct listener moves (a second door spawned beside a live one moves every sticky port, see #370), the allowlist excludes the serving door. The ensureHeadroom gate from #195 refuses correctly, but the supervisor defers its restart until no session is registered, and registered sessions can be days old. A launch that routes no provider is unaffected, and --no-headroom works.
The fix is for the daemon to take a new allowlist at runtime: the supervisor tells the running daemon its new allowlist when the hash drifts, with no restart and no cut-off sessions (a change in the headroom fork, which needs its guard code read first). If the fork cannot reload, the replacing door must keep the retired door's direct origin admitted until that door's sessions are gone. Related: #370 (the duplicate door), #371 (superseded door drain), #372 (drain-then-restart on the gate), #373 (diagnostics).
Activity
Mearman commentedon Oct 11, 2026
Closing criteria, so the issue is not closed on merge alone: after a release carrying #370, #371, #373 and the allowlist file change (#381) is installed and the door has turned over, a provider launch routed through headroom succeeds while an older door's sessions are still registered, and
headroom statusreports no allowlist drift. #372 is subsumed by #381. The headroom change it depends on is ExaDev/headroom#18, and the fork's divergence from upstream is tracked in #382.Mearman commentedon Oct 12, 2026
agent-shim 10.0.0 is published and CI on main is green. The release binary's checksum matches and
headroom statusruns under a throwaway root. The remaining closing step is the live one: upgrading the installed 9.5.0, launching a provider session through headroom after the door turns over, and confirmingheadroom status,doctorandfrontdoor statusreport no allowlist drift and one door. That acts on the sessions registered on the current door, so it waits for an explicit go.Mearman commentedon Oct 12, 2026
Live check on an upgraded install, partial. After updating to 10.0.0, a fresh provider launch routed through headroom succeeded (the request returned normally), and
frontdoor restartreplaced the serving door in place on the same sticky ports with the 10.0.0 build. The headroom daemon and supervisor in that install were started by the earlier release and stay up while sessions are registered against them, so the allowlist-file reload path has not been exercised yet. Leaving this open until a daemon started by 10.0.0 is observed serving a launch whose door address moved. Remaining step: turn the daemon over (stop the old supervisor once its sessions end, or by hand with the owner's go), launch again, and readheadroom statusanddoctor.Mearman commentedon Oct 12, 2026
Observed live on an install upgraded to the release carrying this change. The headroom daemon was replaced by the new generation, which started with the allowlist file option and an owner-only allowlist file naming the serving door's direct origin. A fresh provider launch then routed through the door and headroom and answered, while sessions from earlier generations were still registered. Probing the daemon directly: the door's direct origin as the upstream base URL passed the guard (the request reached the door and was refused there for lack of a token), and a foreign loopback origin was refused with a 400.
headroom statusanddoctorreport the daemon healthy with no allowlist drift; the one remainingdoctorfailure is an older door still serving pre-upgrade sessions, which drains as they end.