feat: Workspace filesystem cleanup #391
1 issue
code-review: Found 1 issue (1 medium)
Medium
Daemon registry lock can leak if startup throws before server.listen callback - `src/daemon.ts:186-197`
The startup registry lock is acquired at line 186, but is only released in three places: (1) the explicit early-exit when another daemon is detected after lock (line 201), (2) the server.on('error', releaseStartupRegistryLock) handler registered at line 412, and (3) the finally block inside the server.listen callback at line 433. If any synchronous or asynchronous code between lock acquisition and server.listen (e.g. buildDaemonToolCatalogFromManifest, loadManifest, startDaemonServer) throws, the lock is never released. The top-level main().catch handler calls process.exit(1) but does not invoke releaseStartupRegistryLock, which can leave a stale lock file blocking subsequent daemon startups for the same workspace.
Duration: 11m 59s · Tokens: 849.1k in / 6.7k out · Cost: $2.74
Annotations
Check warning on line 197 in src/daemon.ts
sentry-warden / warden: code-review
Daemon registry lock can leak if startup throws before server.listen callback
The startup registry lock is acquired at line 186, but is only released in three places: (1) the explicit early-exit when another daemon is detected after lock (line 201), (2) the `server.on('error', releaseStartupRegistryLock)` handler registered at line 412, and (3) the `finally` block inside the `server.listen` callback at line 433. If any synchronous or asynchronous code between lock acquisition and `server.listen` (e.g. `buildDaemonToolCatalogFromManifest`, `loadManifest`, `startDaemonServer`) throws, the lock is never released. The top-level `main().catch` handler calls `process.exit(1)` but does not invoke `releaseStartupRegistryLock`, which can leave a stale lock file blocking subsequent daemon startups for the same workspace.