Repository navigation
A superseded front door should stop taking sessions and exit when its registry empties #371
Description
When a newer door takes over the state file, the previous door keeps running and keeps holding its listeners and sessions until its registry empties, which on a busy machine can be days. The binary turnover path only retires a door at an empty registry too, so a long-lived session pins every generation it ever served.
A door that no longer owns the state file should stop taking new sessions and exit when its own registry is empty, the way the headroom supervisor already treats a superseded supervisor (it serves its remaining sessions and leaves the new owner's record alone). Sessions that still point at the old addresses keep working until they end, and nothing new is routed there.
Activity
feat: drain and exit a front door superseded by another live supervisor
feat: drain and exit a front door superseded by another live supervisor
chore(release): 9.13.0 [skip ci]
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.