Skip to content

Fix daemon registry ownership validation and remove unused function

829b538
Select commit
Loading
Failed to load commit list.
Merged

feat: Workspace filesystem cleanup #391

Fix daemon registry ownership validation and remove unused function
829b538
Select commit
Loading
Failed to load commit list.
@sentry/warden / warden: code-review completed May 4, 2026 in 12m 0s

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

See this annotation in the file changed.

@sentry-warden 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.