pingdotgg / pingdotgg/t3code

[Bug]: Add-project folder picker serves a stale directory listing, folders created outside the app never appear

Open
#11,476 0 comments 0 reactions 0 assignees View on GitHub

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
  1. Open the command palette and start the "Local folder" add-project flow, browsing to some directory, for example ~/Desktop/Personal/.
  2. Close the palette.
  3. Create a new folder inside that directory outside T3 Code (file manager, mkdir, another app).
  4. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.