[Bug]: Project favicon lookup probes ~30 paths one at a time, so a slow disk stalls assets.createUrl for a minute

Open Beginner friendly
#12,542 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
backend, performance

Research direction

Start at apps/server and trace assets.createUrl to ProjectFaviconResolver.resolvePathUncached, then inspect how the 21 well-known paths and 7 source files are probed and prioritized. Reproduce the slow-filesystem case if possible; done means a cold lookup probes candidates concurrently, preserves priority order, and avoids the reported sequential delay.

Written by the indexing model from the issue text.

Description

Area

apps/server

Steps to reproduce
  1. Run the server on a host where filesystem calls are slow (in my case a WSL2 host under heavy memory and I/O pressure, where one stat took 1 to 4 seconds).
  2. Open a client so that it requests project favicon asset URLs (assets.createUrl).
Expected behavior

A favicon lookup costs about one filesystem round trip, because the probes do not depend on each other.

Actual behavior

ProjectFaviconResolver.resolvePathUncached probes 21 well-known paths and then 7 source files one after the other. A miss costs about 30 sequential filesystem calls, so the request time is 30 times the latency of one call. The cache added in #9080 does not help a cold lookup, and a miss stays cached for only 1 minute.

Numbers from server.trace.ndjson during the slow period:

Span Count Median Max
ws.rpc.assets.createUrl 72 38.6 s 79.4 s

One slow call, by child span:

ws.rpc.assets.createUrl                          77697 ms
  AssetAccess.issueAssetUrl                      77648 ms
    WorkspacePaths.normalizeWorkspaceRoot         1241 ms
    ProjectFaviconResolver.resolvePath           60149 ms
      ProjectFaviconResolver.resolvePathUncached 60140 ms
        findExistingFile  1942 ms
        findExistingFile  1781 ms
        findExistingFile  2274 ms
        findExistingFile  4420 ms
        ... (one span for each candidate, in sequence)
    ServerSecretStore.getOrCreateRandom           1435 ms
Impact

On a slow disk or a loaded host, project icons and every other assets.createUrl call for a project favicon wait for a minute or more. The host was the root cause of the slowness in my case, but the sequential walk multiplied it by 30.

Version or commit

0.0.43-nightly.20260918.1895. The code is the same on main at 0f1b572b9.

Environment

Linux (WSL2), server run as a service.

Workaround

None. A proposed fix probes the candidates concurrently and keeps the priority order.

Dominant language
TypeScript
Stars
23.2k
Forks
5.9k
Avg merge
10h 57m
Merged PRs (30d)
365

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.

More from pingdotgg/t3code

All issues in pingdotgg/t3code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.