[Bug]: Repeated slow-request warnings from 21–23s VCS refreshes on a no-remote repo (Windows, 0.0.44) #14352

Root cause narrowed to the already-reported non-zero-exit cleanup mechanism in #2537: the bundled Effect process spawner launches taskkill twice after Git exits and awaits one cleanup call. Isolated original/control measurements and live-span analysis were added in this comment on #2537. Closing this report as a duplicate; the original observations remain below for context.

Before submitting

• I searched existing issues and did not find an exact duplicate.
• I included enough detail to investigate the problem.

Area

apps/server

Summary

T3 Code Desktop 0.0.44 repeatedly displays "Some requests are slow / 1 request waiting longer than 15s", identifying vcs.refreshStatus. On the affected installation, several completed server-side refreshes took about 21–23 seconds for a local Git repository with no configured remote.

The trace includes remote-status and PR-lookup work, repeated remote/branch resolution, and handled No git remote is configured for this repository failures. The top-level refreshes eventually succeed. The absence of a remote is an observed condition, not a proven explanation for all the latency.

Steps to reproduce / observed workflow

1. Open T3 Code Desktop 0.0.44 on Windows with an existing profile and a local Git repository with no remote. git remote prints nothing.
2. Work in a thread and allow VCS status refreshes to run.
3. The slow-request warning repeatedly appears; expanding it shows vcs.refreshStatus.
4. Inspect ~/.t3/userdata/logs/server.trace.ndjson* and follow parentSpanId descendants of a slow ws.rpc.vcs.refreshStatus span.

This was observed repeatedly on an existing installation. A minimal clean-profile reproduction has not been established; creating a new repository with no remote alone has not been shown to reproduce the delay.

Expected behavior

Local Git status should remain responsive for repositories without a remote. Remote/PR discovery should avoid redundant work when no remote exists, and routine background status updates should not repeatedly trigger a disruptive slow-request warning.

Actual behavior

Example completed server-side ws.rpc.vcs.refreshStatus durations from the inspected logs:

20,840.918 ms
22,707.799 ms
20,865.789 ms
20,982.033 ms

The UI warning threshold is 15 seconds. Dismissing the warning does not prevent it from returning for subsequent slow requests.

Version or commit

T3 Code Desktop (Alpha) 0.0.44, stable release. Confirmed from the installed executable and frontend trace resource attributes.

Environment

• Windows 11 Home x64, OS version 10.0.26200.
• Git available in the diagnostic shell: 2.41.0.windows.2.
• Affected repository is on a local Windows drive, has tracked modifications, and has no configured Git remote.
• The affected server trace uses Windows repository paths and the installed resources/server.asar/apps/server/dist/bin.mjs stack.

Logs and measurements

Selected descendant spans from one completed 20,982 ms refresh:

These are nested/concurrent inclusive durations, not additive.

Several GitVcsDriver.readConfigValue spans within that refresh took approximately 1.56–3.14 seconds each. Two resolvePrimaryRemoteName descendants, approximately 1.63 and 1.65 seconds, failed with this sanitized message:

GitCommandError: Git command failed in GitVcsDriver.resolvePrimaryRemoteName (<local-repo>):
No git remote is configured for this repository.

resolvePrimaryRemoteName
  <- resolveBaseBranchForNoUpstream
  <- computeAheadCountAgainstBase
  <- readStatusDetailsLocal / readStatusDetailsRemote

The top-level RPC still exited successfully.

For comparison, separate follow-up checks outside T3, against the same repository while T3 remained open, returned:

git --no-optional-locks -C <local-repo> rev-parse --is-inside-work-tree
69 ms; exit 0; true

git --no-optional-locks -C <local-repo> remote
64 ms; exit 0; empty output

git --no-optional-locks -C <local-repo> status --porcelain=v1 --untracked-files=no
65 ms; exit 0

These are single follow-up measurements, not an A/B benchmark of the same internal command sequence. They do not establish whether T3 is waiting on process execution, scheduling/concurrency, or some other backend work. The shell Git executable/environment has not been verified to match the server's.

Related issues

• [Bug]: Some requests are slow keeps appearing #1986: similar recurring warning, but an older closed report involving fetch timeouts.
• Overlapping VCS status refreshes multiply Git and network work #7076: overlapping explicit VCS refreshes. I have not established that overlapping clients/requests explain this case.
• [Bug]: Changes/Diff view shows 0 changes when the repository has no git remote configured #7662: no-remote handling in diff computation; this report concerns slow status refreshes rather than a missing diff.
• [BUG] ThreadSettlementReactor spawns ~50 git/min even when auto-settle is disabled; vcs.refreshStatus sits at 10s p50 #9714: background Git work and refresh latency; I have not attributed this case to the settlement reactor.

Workaround

No verified workaround. No application settings, installed binaries, Git configuration, or project files were changed during diagnosis.

Report prepared with Codex from local trace inspection and direct Git checks. Private paths, project names, environment identifiers, and chat content are omitted.