Repository navigation
A launch refused by the headroom allowlist gate should make the supervisor drain and restart the daemon #372
Description
ensureHeadroom refuses a provider launch when the running daemon's allowlist does not admit the serving door's origin, naming the launches holding the daemon (#195). The supervisor only restarts the daemon on drift once no session is registered, so the refusal lasts as long as the oldest registered session, which can be days.
The gate should hand the supervisor a drain-then-restart: stop admitting new sessions to the stale daemon, restart once in-flight requests finish, and let the launch proceed against the new daemon. Restarting while requests are in flight cuts off live sessions, so a bare kill is not the answer. This may be subsumed by a runtime allowlist reload in #367; if so this closes with a pointer to it.
Activity
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.