A vue-tui:request-reload arriving during the Ctrl+C shutdown window
spawned an orphan child the parent never kills. The reload path and the
shutdown path did not compose: handleReloadRequest only consulted the 3s
startup gate, never isShuttingDown, so a reload accepted during the
pm.shutdown() teardown window ran extractBundle then pm.restart() — which
schedules a fresh 100ms restartTimer. pm.shutdown() had already cleared
its own restartTimer at entry, so nothing cancels the new one; it fires
doSpawn() and creates a brand-new child after the parent has exited.
Fix mirrors respawnTick's existing two-check guard:
- Fast gate: compose shouldAccept as
`() => acceptReloads && !shutdown.isShuttingDown()` so reloads are
ignored once Ctrl+C teardown begins.
- Post-await guard (load-bearing): thread isShuttingDown into
ReloadRequestDeps and re-check it after `await extractBundle` and
before pm.setBundlePath/pm.restart, covering the case where shutdown
starts mid-extraction.
The hot handler registration is moved after createShutdown() so the
forward reference resolves (closures read at event time regardless).
Scope is only this reload-vs-shutdown guard; respawnTick, createShutdown
internals, process-manager.ts, and bundle-extractor.ts are unchanged.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Yunfei He
900e4176f9