Repository navigation
fix(core): share fff engine per directory - #52964
Shalin-Shah-2002 wants to merge 1 commit into
Conversation
Co-Authored-By: Claude Sonnet 5.5 <[email protected]> Claude-Session: https://claude.ai/code/session_01HfXsWoKF5h7tmdmyUEw1rD
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
|
The following comment was made by an LLM, it may be inaccurate: |
|
#50966 was closed as a v1 issue; the v2 report is #54631, where the duplicate engine was reproduced. On |
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
Issue for this PR
Fixes #50966
Type of change
What does this PR do?
Each
fffLayerbuild callsFff.create({ basePath }), and every engine owns its own file index and inotify watcher.LocationServiceMap.reload()boots the replacement graph while running sessions still borrow the old one, so for the same directory the old and new graph each hold an engine. The kernel doesn't dedupe watches across inotify instances, so the watch count and the in-memory index double.fffLayernow keeps a module-level map of engines by directory. A build reuses the engine for its directory and bumps a user count, and the finalizer only destroys the engine when the last user closes. Engine options are constants, so sharing doesn't change behavior. I did not touchLocationServiceMap.canonical; refs that resolve to the same directory through a symlink would still get separate engines.How did you verify your code works?
Added
packages/core/test/location-search.test.ts:LocationServiceMap.reload(), and asserts one live engine for that directory. Before the change it fails with 2 live engines; after, it passes.fffLayertwice for one directory and asserts the engine survives closing the first scope and is destroyed when the second closes.bun testfortest/filesystem/search.test.ts,test/location-layer.test.ts,test/location-filesystem.test.tsand the new file: 41 pass. The fullpackages/coresuite has the same 41 failures with and without this change (Ripgrep and ShellTool tests; norgbinary and no native tree-sitter build in my environment).bun run typecheckinpackages/coreis clean. (An earlier run showed 3 errors insrc/plugin/command.ts; they came from stale dependencies in my checkout and are gone afterbun install.)I could only measure this on macOS, not by counting inotify watches on Linux as the issue does.
Screenshots / recordings
N/A
Checklist
🤖 Generated with Claude Code
https://claude.ai/code/session_01HfXsWoKF5h7tmdmyUEw1rD