The run loop error handler in Kernel.ts:297-306 catches the error, logs Run loop error (kernel may be non-functional):, and deliberately does not re-throw or change kernel state.
Consequences: the run loop stops, but the daemon process stays up, the control socket keeps answering, and getStatus() continues to report a healthy kernel. Nothing on the run queue is processed. The outage is total, silent, and undetectable from outside the process.
Proposed:
- Record an unhealthy/faulted state when the run loop terminates unexpectedly.
- Surface it in
getStatus() so it is externally observable.
- Either exit non-zero (letting a supervisor restart) or expose an explicit restart path — whichever we prefer, but the current "stay up and pretend" behaviour should not be an option.
- Add a test that induces a run-loop failure and asserts the kernel reports unhealthy.
Related: this is a prerequisite for a meaningful health endpoint.
The run loop error handler in
Kernel.ts:297-306catches the error, logsRun loop error (kernel may be non-functional):, and deliberately does not re-throw or change kernel state.Consequences: the run loop stops, but the daemon process stays up, the control socket keeps answering, and
getStatus()continues to report a healthy kernel. Nothing on the run queue is processed. The outage is total, silent, and undetectable from outside the process.Proposed:
getStatus()so it is externally observable.Related: this is a prerequisite for a meaningful health endpoint.