Bug
When a thread crashes mid-execution (e.g. unhandled error during stream()), the thread state remains running in the database. On next request to that thread, it throws:
error: thread already running
at stream (packages/kernl/dist/thread/thread.js:124:23)
The thread becomes permanently unusable without manual DB intervention.
Root cause
thread.stream() guards against concurrent execution by checking this.state === RUNNING, but if the process crashes or the stream errors out without hitting the finally/cleanup path, the state is never reset in storage.
Expected behavior
- Thread state should be reset to
stopped (or failed) on crash/error
- On startup, any threads left in
running state should be recovered (they can't actually be running if the server just started)
Workaround
Manual DB fix:
UPDATE kernl_threads SET state = 'stopped' WHERE state = 'running';
Affected code
packages/kernl/src/thread/thread.ts — stream() method, state guard at line ~122packages/storage/ — no recovery logic on init
Bug
When a thread crashes mid-execution (e.g. unhandled error during
stream()), the thread state remainsrunningin the database. On next request to that thread, it throws:The thread becomes permanently unusable without manual DB intervention.
Root cause
thread.stream()guards against concurrent execution by checkingthis.state === RUNNING, but if the process crashes or the stream errors out without hitting the finally/cleanup path, the state is never reset in storage.Expected behavior
stopped(orfailed) on crash/errorrunningstate should be recovered (they can't actually be running if the server just started)Workaround
Manual DB fix:
Affected code
packages/kernl/src/thread/thread.ts—stream()method, state guard at line ~122packages/storage/— no recovery logic on init