Skip to content

fix(mcp): release an idle explicit project and its writer lock (#2087) - #2093

Closed
danusha2345 wants to merge 1 commit into
colbymchenry:mainfrom
danusha2345:fix/2087-release-secondary-writer-lock
Closed

danusha2345 wants to merge 1 commit into
colbymchenry:mainfrom
danusha2345:fix/2087-release-secondary-writer-lock

Conversation

@danusha2345

Copy link
Copy Markdown
Contributor

Fixes #2087 (reported, with the idle-release approach, by @bompus — thanks).

When a daemon answers a projectPath query for another indexed project that has no owner, it opens that project in-process and takes its writer lock (#1835). The project cache only evicted over its LRU bound or on shutdown, so the lock stayed held for the daemon's whole life: the project's own daemon could not become its writer and codegraph index there was refused until the first daemon exited.

This releases a cached explicit project after it has gone unused for 10 minutes (CODEGRAPH_PROJECT_IDLE_TIMEOUT_MS; 0 never releases). The release goes through the same path as LRU eviction, so an in-flight call or a still-running catch-up defers it, and it frees the SQLite handle, the watcher, the writer lock and any held daemon session. The next call reopens the project and catches it up, so #1835's "explicit projects stay synchronized while in use" is unchanged.

Not taking the writer lock at all was considered and rejected: a project with no daemon of its own would then go unsynchronized while it is being queried.

Interaction with #1929 (keep active MCP project connections open): both touch the cache-trim loop in src/mcp/tools.ts; the merge is mechanical (keep #1929's guard for projects with active calls and this idle condition), and the idle timer should skip busy projects when it picks the next one.

Tests

Real temp projects and SQLite, in __tests__/mcp-projectpath-lifecycle.test.ts:

  • an idle explicit project releases writer.pid, and the next call reopens it, catches up an edit and takes the lock again;
  • an idle release waits for an active catch-up to finish.

Both fail on main and pass with the fix; the existing lifecycle / writer-lock suites pass. Full suite on Linux: everything passes except ui-package.test.ts > is versioned with the engine, which fails on main too (ui/package.json is still 1.6.0 after the 1.6.1 bump).

🤖 Generated with Claude Code

…mchenry#2087)

A daemon that answered a `projectPath` query for another indexed project
opened it in-process and, with no owner there, took its writer lock. The
project cache only evicted over its LRU bound or on shutdown, so the lock
stayed held for the daemon's whole life: the project's own daemon could not
become its writer and `codegraph index` there was refused.

Release a cached explicit project once it has gone unused for 10 minutes
(CODEGRAPH_PROJECT_IDLE_TIMEOUT_MS; 0 never releases), through the same
trim path as LRU eviction, so an active call or a running catch-up still
defers it. The next call reopens the project and catches it up (colbymchenry#1835).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@colbymchenry

Copy link
Copy Markdown
Owner

Thank you! This landed in #2283: your commit carried onto current main with its authorship kept, plus a changelog credit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

A daemon keeps the writer lock of a project it opened for one projectPath query

2 participants