[Bug]: Add-project folder picker serves a stale directory listing, folders created outside the app never appear
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 23k
- Forks
- 5.9k
- Avg merge
- 11h 14m
- Merged PRs (30d)
- 357
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web (the same code path is shared with apps/mobile through packages/client-runtime)
Steps to reproduce
- Open the command palette and start the "Local folder" add-project flow, browsing to some directory, for example
~/Desktop/Personal/. - Close the palette.
- Create a new folder inside that directory outside T3 Code (file manager,
mkdir, another app). - Reopen the palette and browse to the same directory again.
Expected behavior
The listing reflects the directory on disk: the new folder appears when the picker is reopened.
Actual behavior
The listing is the cached one from the previous open. The new folder does not appear, no matter how many times the picker is closed and reopened, until roughly 5 minutes of not touching that directory have passed. There is also no manual refresh affordance in the picker to force it.
Impact
Minor bug or occasional failure
Version or commit
main @ c0ddfb3a8
Environment
Linux desktop app and web, reproduced against a local environment
Root cause
The browse listing comes from the filesystem.browse query atom family, which is wired with Atom.swr({ staleTime: 30_000, revalidateOnMount: true }) plus Atom.setIdleTTL(5 * 60_000) in packages/client-runtime/src/state/runtime.ts (createEnvironmentQueryAtomFamily).
Atom.swr only re-checks staleness inside its transform build function, which runs when the atom node is (re)built. The idle TTL keeps the node alive for 5 minutes after the palette closes, so reopening the picker resubscribes to a warm node and simply reads the cached value: the swr staleness check never runs, revalidateOnMount never fires, and no refetch happens. The listing is effectively frozen for the idle TTL window even though staleTime is 30 seconds.
Web (CommandPalette browse mode) and mobile (FolderBrowser in AddProjectScreen) both consume this atom family and both exhibit the staleness.
Workaround
Leave that directory unvisited for over 5 minutes so the idle TTL drops the atom node, or restart the client.
Notes
A minimal fix is ready on a branch (revalidate once when a picker mounts onto a warm cached atom, on web and mobile), happy to open a PR. The missing "new folder" affordance that makes this sting extra is already proposed in discussion #10353.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with packages/client-runtime/src/state/runtime.ts and the createEnvironmentQueryAtomFamily setup for filesystem.browse. Trace how the web CommandPalette browse mode and mobile FolderBrowser consume the atom when reopened with a warm cached node. Done means both pickers show a folder created outside the app after reopening, without waiting for the idle TTL; verify on web and mobile.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend, mobile
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 72/100