You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(server): file search no longer freezes the server while fff's watcher reads a large file - #36273
Review item confirmed and fixed: fff's isScanning takes the picker lock, so WorkspaceSearchIndex's two remaining sync calls could still block the event loop while the watcher reads a large file. Those calls were scanSymlinkEntries' indexComplete check, which runs on a first or stale symlink scan before a name search, and hasIncompleteInitialScan after an initial scan timeout. Both now go through one isScanning Effect that awaits finder.getScanProgressAsync(), the existing off-thread progress read added by the fff-node patch in #35460 (runInNewThread, shared by concurrent callers per finder). A failed or rejected read counts as still scanning: search marks the result truncated and keeps the symlink scan result only briefly. hasIncompleteInitialScan returns an Effect, so list and search now yield it. The fff patch is unchanged from ff77366. Not re-measured against a large file in this round; the fix relies on getScanProgressAsync already being off-thread.
Commit 9b5d997 (origin/main). (1) Mechanism probe: @ff-labs/fff-node 0.11.0 from apps/server, FileFinder.create on a 50-file non-git folder with the same options WorkspaceSearchIndex uses; renamed a 6 GB plain-text file whose page cache had been dropped (posix_fadvise DONTNEED) into the folder; the next synchronous finder.mixedSearch("") blocked the Node event loop for 10,794 ms. (2) Real app: T3CODE_DEV_SEED=0 vp run dev (fresh database), web client driven by headless Chromium (Playwright). Added a non-git project with 50 small files via t3 project add, created a thread in it with the Replay (dev) provider, opened that thread, and typed @src in the composer (projects.searchEntries -> WorkspaceSearchIndex.search -> mixedSearch). Then moved the uncached 6 GB text file into the project root and typed one more character every ~750 ms, while a loop fetched /api/projects from the server every 200 ms. Result: a single WorkspaceSearchIndex.runSearch span took 9,470 ms. Unrelated RPCs (orchestration.searchThreads, server.refreshProviders, server.reportClientActivity) were queued behind it for up to 9.5 s. The HTTP probe took 9,365 ms (baseline under 210 ms). The composer popup sat on 'Searching workspace files…'. The same steps with a git repository as the project did not stall (searches 5-40 ms, probes under 210 ms), so the freeze shows on non-git roots such as a home directory, as reported.
Evidence
Fresh databases, Linux web dev servers, headless Chromium, 1440×900, dark theme, and Replay (dev) on both sides. In matching non-git projects with 50 small files, type @src, rename an uncached 6 GiB text file into the root, and continue typing every approximately 750 ms while probing /api/projects every 200 ms.
Search span: 14,884 ms. Unrelated HTTP request: 14,890 ms; baseline maximum 31 ms. Composer remains on “Searching workspace files…”.
Search still waits 12,866 ms, but the slowest unrelated HTTP request is 95 ms; baseline maximum 33 ms. All 154 probes return HTTP 200.
The fix isolates the slow search from the server event loop. Recordings include an explicitly labeled external measurement display; host information is redacted.
A minutes-long stall and real home-directory contents were not exercised; the synthetic non-git root reproduced the watcher-lock freeze for approximately 15 seconds without accessing private files.
Other search entry points and the initial-scan timeout path were not exercised.
Tests
vp test run src/workspace/ src/orchestration-v2/RunFinalizationService.test.ts (apps/server): 6 files, 86 tests passed. vp test run src/workspace/WorkspaceSearchIndex.test.ts, with fakeSymlinkFinder's isScanning now throwing: 10 passed with the fix; with WorkspaceSearchIndex.ts reverted to ff77366, 8 failed. vp run check:changed: unused patches, format, lint, knip 1/2 and 2/2, graphql, typecheck (41 packages), tests (3 files) all passed.
Not in this change
If four or more finders wait on fff's lock at once, the shared 4-thread libuv pool (also used by fs and dns) can still fill; raising UV_THREADPOOL_SIZE or adding a global cap would be a separate change.
fff's watcher still reads each new file to EOF with no size cap while holding the picker lock (an upstream fff issue); searches on that one index stay slow until the read finishes.
Searches queued behind a held lock still run after it is released even when their RPC was interrupted; dropping superseded queries would be a separate change.
If four or more finders wait on fff's lock at once, the shared 4-thread libuv pool can still fill; raising UV_THREADPOOL_SIZE or a global cap would be a separate change.
Who did the work
Written by Claude Opus 5.5, in Claude Code
Reviewed by GPT-6.1 Sol, in Codex, and by Claude Opus 5.5, each on its own
Proof captured by GPT-6.1 Sol and checked by Claude Opus 5.5
…cher reads a large file
fff's watcher holds its picker lock while it reads each new file to the
end, so in a non-git root one large or slow file blocked every search,
and closing an index, on the event loop for as long as that read took.
The fff-node patch adds fileSearchAsync, directorySearchAsync,
mixedSearchAsync and grepAsync, which run the native search on a libuv
pool thread. Searches on one finder run one at a time, so a held lock
occupies at most one pool thread per finder. destroy() now frees the
handle on a pool thread too. WorkspaceSearchIndex uses the async calls.
Fixes#11306
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fff's isScanning takes the same picker lock the watcher holds while it
reads a new file, so the symlink scan and the timed-out initial scan
check could still block the event loop before a search went off-thread.
Both now read scan progress through getScanProgressAsync.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Macroscope's review found this PR approvable — Workspace searches and finder cleanup move off the JavaScript thread to avoid freezing the server during watcher lock contention. Searches are serialized per finder, and cleanup waits for pending native calls; no product-default or diagnostic-suppression changes are introduced.
You can add or adjust custom eligibility rules. Learn more.
No actionable comments were generated in the recent review.
Walkthrough
FileFinder adds asynchronous native operations. WorkspaceSearchIndex uses asynchronous search and scan-progress calls for workspace listing and search. Tests use asynchronous FileFinder mocks and check that selected paths do not call synchronous APIs.
FileFinder adds asynchronous scan, search, grep, and scan-progress methods that run native operations on native threads. Searches are serialized, destruction waits for pending work, and parsing changes include a 200-item limit for per-item scores.
sequenceDiagram
participant WorkspaceSearchIndex
participant FileFinder
participant NativeLoader
WorkspaceSearchIndex->>FileFinder: Request async search or scan progress
FileFinder->>NativeLoader: Run FFI operation on native thread
NativeLoader-->>FileFinder: Return operation result
FileFinder-->>WorkspaceSearchIndex: Resolve asynchronous result
Loading
Suggested reviewers:t3dotgg, sidhartha1s
Merge Risk: Minimal · up to 9d7e5
This change moves workspace file search and scan-progress checks off the server's main thread, so a busy file watcher should no longer freeze the Files panel. No actionable merge-blocking risk was found. The fix has not been re-measured against a very large file.
Pre-merge checks: 3 · 1
Failed checks: 1 inconclusive
Check name
Status
Explanation
Resolution
Out of Scope Changes check
The core changes are in scope: WorkspaceSearchIndex.ts, its tests, WorkspaceEntries.test.ts (a grep guard), and the fff-node patch that supplies getScanProgressAsync and the other async methods. The p…
Explain in the PR description why each non-async patch change (CJS export path, asar.unpacked binary resolution, FFI string decoding and types, path_alignment_bonus) is required for this fix. If one is not required, move it to a separate ch…
Passed checks: 3 passed
Check name
Status
Explanation
Title check
The title names the main change: file search in the server no longer blocks while fff's watcher reads a large file. The changeset moves WorkspaceSearchIndex's remaining synchronous fff scan-state read…
Linked Issues check
[#11306] Requirement: synchronous file-search work must not block the backend event loop, and a busy watcher must not hang the Files panel call. The change summary for apps/server/src/workspace/Worksp…
Description check
The description follows the repository template closely. It has Problem, Change, Scope, and Verification sections, and it links issue #11306. The Problem section explains the event-loop stall from fff…
Full details: Title check
Explanation
The title names the main change: file search in the server no longer blocks while fff's watcher reads a large file. The changeset moves WorkspaceSearchIndex's remaining synchronous fff scan-state reads (isScanning and hasIncompleteInitialScan) to the asynchronous getScanProgressAsync path, which addresses that freeze. The title follows a conventional commit format and is specific.
Full details: Linked Issues check
Explanation
[#11306] Requirement: synchronous file-search work must not block the backend event loop, and a busy watcher must not hang the Files panel call. The change summary for apps/server/src/workspace/WorkspaceSearchIndex.ts states that searches, scan-progress checks, and refresh scans move from synchronous FileFinder calls to async counterparts (mixedSearchAsync, fileSearchAsync, grepAsync, getScanProgressAsync). The symlink indexComplete check and hasIncompleteInitialScan now use one isScanning Effect that awaits getScanProgressAsync(). A failed or rejected read counts as still scanning, so the search returns a truncated result instead of failing. The fff-node patch adds the async methods on native threads. Tests in WorkspaceSearchIndex.test.ts were updated to async mocks, and the symlink finder's isScanning mock throws on the JS thread. The PR reports 10 passing tests with the fix and 8 failures with the old file. The issue's suggested fix (off-thread mixedSearch and isScanning) is implemented in code. The PR states that the real-app timing was not re-measured after the fix, so the runtime improvement is not yet measured. Home-directory scanning defaults are not changed, which the issue lists only as an optional alternative.
Full details: Description check
Explanation
The description follows the repository template closely. It has Problem, Change, Scope, and Verification sections, and it links issue #11306. The Problem section explains the event-loop stall from fff's picker lock. The Change section names the two synchronous calls that now go through getScanProgressAsync and states the failure behavior. The Scope section links the issue that shows the bug. The Verification section gives specific test commands, counts, and before/after measurements, and it lists what was not checked. It also names the models and harness used, as the template asks. The description is long and includes a 'Not in this change' section, which goes beyond the template. Those parts are non-critical, so they do not lower the assessment. The title is absent from the provided text, so the conventional commit title requirement cannot be verified. That is a minor gap.
Full details: Out of Scope Changes check
Explanation
The core changes are in scope: WorkspaceSearchIndex.ts, its tests, WorkspaceEntries.test.ts (a grep guard), and the fff-node patch that supplies getScanProgressAsync and the other async methods. The patch diff against the merge base is +204/-27 and includes items that the PR description does not mention: the CommonJS package export changing from dist/index.cjs to dist/index.js, NPM-package binary resolution that checks for an .asar.unpacked counterpart, FFI string-pointer decoding and string data-type changes, and a path_alignment_bonus score field. The PR description says the patch is unchanged from ff77366 and that the async progress read comes from #35460. It does not explain why those other patch changes are needed for this issue. Whether they come from #35460 or are unrelated could not be established from the summary alone, and no repository inspection was performed in this assessment.
Resolution
Explain in the PR description why each non-async patch change (CJS export path, asar.unpacked binary resolution, FFI string decoding and types, path_alignment_bonus) is required for this fix. If one is not required, move it to a separate change or remove it. If #35460 already contains these changes, confirm that by citing the base revision that includes them.
Finishing Touches
Generate unit tests (beta)
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 1 remain after this review.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size:L100-499 changed lines (additions + deletions).vouch:trustedAuthor is trusted by repo permissions or the VOUCHED list.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
vouch:trusted
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
Review item confirmed and fixed: fff's isScanning takes the picker lock, so WorkspaceSearchIndex's two remaining sync calls could still block the event loop while the watcher reads a large file. Those calls were scanSymlinkEntries' indexComplete check, which runs on a first or stale symlink scan before a name search, and hasIncompleteInitialScan after an initial scan timeout. Both now go through one isScanning Effect that awaits finder.getScanProgressAsync(), the existing off-thread progress read added by the fff-node patch in #35460 (runInNewThread, shared by concurrent callers per finder). A failed or rejected read counts as still scanning: search marks the result truncated and keeps the symlink scan result only briefly. hasIncompleteInitialScan returns an Effect, so list and search now yield it. The fff patch is unchanged from ff77366. Not re-measured against a large file in this round; the fix relies on getScanProgressAsync already being off-thread.
Fixes #11306
Reproduction on main
Commit 9b5d997 (origin/main). (1) Mechanism probe: @ff-labs/fff-node 0.11.0 from apps/server, FileFinder.create on a 50-file non-git folder with the same options WorkspaceSearchIndex uses; renamed a 6 GB plain-text file whose page cache had been dropped (posix_fadvise DONTNEED) into the folder; the next synchronous finder.mixedSearch("") blocked the Node event loop for 10,794 ms. (2) Real app:
T3CODE_DEV_SEED=0 vp run dev(fresh database), web client driven by headless Chromium (Playwright). Added a non-git project with 50 small files viat3 project add, created a thread in it with the Replay (dev) provider, opened that thread, and typed@srcin the composer (projects.searchEntries -> WorkspaceSearchIndex.search -> mixedSearch). Then moved the uncached 6 GB text file into the project root and typed one more character every ~750 ms, while a loop fetched /api/projects from the server every 200 ms. Result: a single WorkspaceSearchIndex.runSearch span took 9,470 ms. Unrelated RPCs (orchestration.searchThreads, server.refreshProviders, server.reportClientActivity) were queued behind it for up to 9.5 s. The HTTP probe took 9,365 ms (baseline under 210 ms). The composer popup sat on 'Searching workspace files…'. The same steps with a git repository as the project did not stall (searches 5-40 ms, probes under 210 ms), so the freeze shows on non-git roots such as a home directory, as reported.Evidence
Fresh databases, Linux web dev servers, headless Chromium, 1440×900, dark theme, and Replay (dev) on both sides. In matching non-git projects with 50 small files, type
@src, rename an uncached 6 GiB text file into the root, and continue typing every approximately 750 ms while probing/api/projectsevery 200 ms.The fix isolates the slow search from the server event loop. Recordings include an explicitly labeled external measurement display; host information is redacted.
Browser driver · Synthetic seed and setup · Measurements and span durations
Not shown:
Tests
vp test run src/workspace/ src/orchestration-v2/RunFinalizationService.test.ts (apps/server): 6 files, 86 tests passed. vp test run src/workspace/WorkspaceSearchIndex.test.ts, with fakeSymlinkFinder's isScanning now throwing: 10 passed with the fix; with WorkspaceSearchIndex.ts reverted to ff77366, 8 failed. vp run check:changed: unused patches, format, lint, knip 1/2 and 2/2, graphql, typecheck (41 packages), tests (3 files) all passed.
Not in this change
Who did the work
Run by the t3code factory in T3 Code.