Uncached project favicon discovery amplifies reconnect hydration into slow RPCs and disconnects

[Tylerjet]

What happened

I am receiving a lot of slow to respond errors which causes the local client to report as disconnected so I cannot send new messages or interact with actions in the T3 Code UI.

The desktop client repeatedly reports slow requests, then marks its managed local server as disconnected. While disconnected, messages cannot be sent and UI actions do not work, although active provider work may continue in the background.

Diagnosis

Trace analysis against the source matching the installed build found that project favicon requests dominate the slow RPCs.

For every assets.createUrl request for a project favicon, AssetAccess.issueAssetUrl calls ProjectFaviconResolver.resolvePath. The resolver has no per-workspace cache or single-flight deduplication, so concurrent requests for the same project repeat the complete candidate and source-file discovery process.

Reconnect and sidebar hydration can issue hundreds of these requests. In the affected connection traces:

• 97 of 105 tracked RPCs exceeding 15 seconds were assets.createUrl.
• The slow favicon requests took up to 52.301 seconds.
• 476 assets.createUrl spans led to 475 AssetAccess.issueAssetUrl spans.
• 461 ProjectFaviconResolver.resolvePath spans produced 9,670 findExistingFile spans across 11 affected connection traces.
• All 12 affected connection traces included SessionStore.markDisconnected.
• 23 distinct transport incidents occurred in the analyzed 60-minute window.

On-demand VCS activity also appeared in the affected traces and likely compounds the contention, but only eight slow RPC roots were VCS operations. The favicon path was the dominant repeated workload.

Live follow-up health probes returned HTTP 200 for 15/15 requests with a 1 ms median and 75 ms maximum. The server process remained responsive and provider event logs continued advancing. This points to a busy/starved transport path rather than a crashed process or network outage.

The previously reported unanchored favicon regex is no longer present in this build. Here the resolver calls complete but are repeated hundreds of times without caching or deduplication.

Steps to reproduce

A clean-profile deterministic UI reproduction has not yet been produced. The observed sequence is:

1. Run the T3 Code desktop app with retained projects and threads.
2. Use the default flat sidebar (legacySidebarEnabled: false).
3. Use projects that do not all have an explicit t3.json iconPath or immediately discoverable favicon.
4. Allow normal sidebar/project hydration and use the client until a transport reconnect occurs.
5. During reconnect hydration, inspect server.trace.ndjson.
6. Observe repeated ws.rpc.assets.createUrl → AssetAccess.issueAssetUrl → ProjectFaviconResolver.resolvePath calls for the same workspaces.
7. Observe each resolver invocation repeating the findExistingFile candidate probes.
8. Under concurrent sidebar/VCS activity, ordinary RPCs exceed 15 seconds and the client reports itself disconnected.

A direct server-side performance reproduction would issue concurrent project-favicon assets.createUrl requests for the same workspace and verify that favicon discovery is performed once per request rather than shared or cached.

Version

T3 Code 0.0.34-nightly.20260819.1133
Tag: v0.0.34-nightly.20260819.1133
Commit: 24c4ba68f536d56e8482a1e4d7070a6771da551d

Environment

Windows 11 x64, build 10.0.26200
Node.js 22.22.3
T3 Code Nightly desktop app using its managed local server
Codex provider

Evidence

Sanitized 60-minute trace summary

Slow tracked RPC roots (>15 seconds): 105
 assets.createUrl: 97, maximum 52.301 seconds
 vcs.refreshStatus: 2, maximum 40.543 seconds
 vcs.listRefs: 6, maximum 24.984 seconds

Affected favicon connection traces: 12
 ws.rpc.assets.createUrl spans: 476
 AssetAccess.issueAssetUrl spans: 475
 ProjectFaviconResolver.resolvePath spans: 461
 ProjectFaviconResolver.findExistingFile spans: 9670
 traces containing SessionStore.markDisconnected: 12/12

Distinct transport incidents: 23

Live server follow-up:
 health responses: 15/15 HTTP 200
 median: 1 ms
 maximum: 75 ms
 desktop process: alive and responding
 provider event logs: continued advancing

Counts are grouped by root trace where appropriate; nested failure spans are not reported as separate incidents. Project names, paths, thread identifiers, and user content have been removed.

Related issues

• [Bug]: Local backend becomes CPU-bound and unresponsive during idle VCS/provider refreshes, causing reconnects #4773 — same reconnect symptom caused by Sidebar V2/VCS request storms. VCS work co-occurs here, but this issue covers the separate dominant favicon request path.
• [Bug]: Unanchored favicon regex pins the server event loop, wedging the environment into a permanent reconnect loop #5537 — closed issue for one pathological unanchored-regex scan. This build contains that fix; the current problem is repeated otherwise-normal discovery with no cache or single-flight behavior.
• Increase Effect RPC ping timeout for large snapshots #3817 — increases RPC ping tolerance, which may reduce disconnect symptoms but does not remove the repeated favicon work.

Fix applied or workaround

No fix was applied during this issue-only triage.

The Battery Saver background profile was already persisted, automatic Git fetch was disabled, and provider health refresh was set to 15 minutes. The problem still recurred.

Enabling Settings → Legacy features → Sidebar (legacy) may reduce sidebar-driven hydration work, but this workaround has not yet been applied or verified on the affected installation.

Providing an explicit t3.json iconPath may let individual projects bypass parts of favicon discovery, but that has also not been tested as a complete workaround.

Filed by

Codex (GPT-5) via t3 triage

[Tylerjet]

Fresh recurrence on v0.0.34-nightly.20260819.1133 while Battery Saver, disabled automatic Git fetch, and the 15-minute provider-health interval remained persisted.

The client reported /api/auth/websocket-ticket timing out after 10 seconds. The desktop process remained alive, and subsequent authenticated ticket requests recovered with HTTP 200.

A 60-request unauthenticated probe of the same POST route had no failures, with a 688 ms median and 5,028 ms maximum, confirming an intermittent stall.

Immediately after reconnect, assets.createUrl calls took 15–21 seconds, favicon resolution 8–13 seconds, and repository identity work up to 11 seconds. Separately, 42,799 of 52,663 spans across approximately 52 seconds were shell.isExecutableFile, matching the tracing-amplification mechanism described in PR #4778.

The original timeout segment rotated out under the high trace volume, so direct attribution remains an evidence-backed inference rather than a captured ticket span.

Collected by Codex (GPT-5) via t3 triage.

[juliusmarminge]

Fixed in #9080. Project favicon resolution is now cached per workspace, so reconnects no longer repeat the full discovery scan for every icon request. Closing this report.