What happened
On a large workspace the Files panel is permanently unusable. Every attempt shows:
Failed to list workspace entries in 'D:\Workspace'.
The surfaced message does not name the cause. The real cause is only visible in
~/.t3/userdata/logs/server.trace.ndjson, nested inside exit.cause:
ProjectListEntriesError: Failed to list workspace entries in 'D:\Workspace'.
[cause]: WorkspaceSearchIndexScanTimedOut: Workspace search index for
'D:\Workspace' did not finish scanning within 15 seconds
Why this is a hard wall rather than a slow path
WORKSPACE_INDEX_SCAN_TIMEOUT_MS is 15000 and is compiled in. There is no setting in
Settings, in settings.json or in client-settings.json that changes it. When the scan
exceeds it, waitForIndexReady fails and the whole projects.listEntries call fails.
No partial listing is returned, so the panel shows nothing at all.
WORKSPACE_INDEX_IDLE_TTL is 15 minutes, so the index is dropped while idle and the
failure repeats on every later use. There is no state in which the panel recovers.
A fixed wall-clock budget for an operation whose cost varies tenfold
Two durations of WorkspaceSearchIndex.waitForIndexReady from the rotated trace logs,
same machine, same workspace, nothing changed in between on my side:
| Date |
Duration |
Outcome |
| 2026-09-08 |
10232 ms |
scan completed, panel worked |
| 2026-09-09 |
15028 ms |
deadline hit, panel dead |
I cannot tell you why the second one was slower, and that is the point. To find out, I
timed an equivalent directory walk over the same tree in two cache states:
| Walk |
Files |
Duration |
| Cold OS metadata cache |
146377 |
100.8 s |
| Warm OS metadata cache |
146377 |
9.9 s |
| Warm, with build and VCS directories excluded |
93482 |
3.2 s |
The operating system's directory-metadata cache is worth about a factor of ten here.
Cutting the tree by 36 % is worth about a factor of three. So a fixed 15-second budget is
being applied to work whose real cost swings by an order of magnitude for reasons that
have nothing to do with the workspace: a reboot, memory pressure, another process
evicting the cache, a slower disk.
That makes the failure intermittent rather than deterministic, which is far harder to
diagnose than a clean size limit. It also means every large workspace is at its most
fragile right after a reboot, exactly when a user is most likely to open the app.
For scale, the tree the indexer actually walks:
| Level |
Files |
| Total in tree |
655098 |
Under node_modules (already excluded by T3) |
478681 |
| Effectively scanned |
146377 |
I deliberately quote no files-per-second figure for T3 itself. The 15028 ms scan never
finished, so its rate is unknown, and the cache measurements above show that any such
figure is meaningless without stating the cache state it was taken in.
Environment
- T3 Code 0.0.40 (Alpha), installed via
winget install T3Tools.T3Code
- Windows 10 Home 19045, workspace on a local NTFS drive
- Workspace is not a git repository; it is a Subversion working copy
- Reinstalling does not help, since nothing about the install is at fault
Suggested fixes, in order of preference
- Return whatever the scan has found when the deadline passes, and mark the listing as
incomplete, instead of failing the entire call. A truncated file tree is far more
useful than an error string.
- Make the timeout configurable per project or globally.
- Keep a successful index across the idle TTL for workspaces whose scan is known to be
slow, so the cost is paid once rather than every 15 minutes.
Related to #4640, which reports the sibling problem of silent truncation at 25,000
entries. Both come down to the same thing: large workspaces have no supported path.
What happened
On a large workspace the Files panel is permanently unusable. Every attempt shows:
The surfaced message does not name the cause. The real cause is only visible in
~/.t3/userdata/logs/server.trace.ndjson, nested insideexit.cause:Why this is a hard wall rather than a slow path
WORKSPACE_INDEX_SCAN_TIMEOUT_MSis 15000 and is compiled in. There is no setting inSettings, in
settings.jsonor inclient-settings.jsonthat changes it. When the scanexceeds it,
waitForIndexReadyfails and the wholeprojects.listEntriescall fails.No partial listing is returned, so the panel shows nothing at all.
WORKSPACE_INDEX_IDLE_TTLis 15 minutes, so the index is dropped while idle and thefailure repeats on every later use. There is no state in which the panel recovers.
A fixed wall-clock budget for an operation whose cost varies tenfold
Two durations of
WorkspaceSearchIndex.waitForIndexReadyfrom the rotated trace logs,same machine, same workspace, nothing changed in between on my side:
I cannot tell you why the second one was slower, and that is the point. To find out, I
timed an equivalent directory walk over the same tree in two cache states:
The operating system's directory-metadata cache is worth about a factor of ten here.
Cutting the tree by 36 % is worth about a factor of three. So a fixed 15-second budget is
being applied to work whose real cost swings by an order of magnitude for reasons that
have nothing to do with the workspace: a reboot, memory pressure, another process
evicting the cache, a slower disk.
That makes the failure intermittent rather than deterministic, which is far harder to
diagnose than a clean size limit. It also means every large workspace is at its most
fragile right after a reboot, exactly when a user is most likely to open the app.
For scale, the tree the indexer actually walks:
node_modules(already excluded by T3)I deliberately quote no files-per-second figure for T3 itself. The 15028 ms scan never
finished, so its rate is unknown, and the cache measurements above show that any such
figure is meaningless without stating the cache state it was taken in.
Environment
winget install T3Tools.T3CodeSuggested fixes, in order of preference
incomplete, instead of failing the entire call. A truncated file tree is far more
useful than an error string.
slow, so the cost is paid once rather than every 15 minutes.
Related to #4640, which reports the sibling problem of silent truncation at 25,000
entries. Both come down to the same thing: large workspaces have no supported path.