Overlapping VCS status refreshes multiply Git and network work

Area

apps/server

Steps to reproduce

1. Open the same environment and repository from multiple T3 clients or windows.
2. Use a repository where local and remote status refreshes are slow enough to overlap.
3. Trigger several focus, visibility, or manual refresh events while the first vcs.refreshStatus request is still running.
4. Inspect RPC spans and Git/network activity.

Expected behavior

At most one explicit VCS status refresh runs per repository. Concurrent callers share that refresh, and redundant client signals waiting behind an active request coalesce to the latest request.

Actual behavior

Each overlapping RPC independently invalidates the repository status cache and starts another local/remote refresh. This bypasses the value of the cache and multiplies Git and network work at exactly the point where the first refresh is already slow.

In one trace, successful overlapping ws.rpc.vcs.refreshStatus spans climbed from 15.8 seconds to 24.1 seconds and repeatedly triggered the UI's request-over-15-seconds warning. The additional load also amplified an unrelated period of server memory pressure.

Impact

Major degradation or frequent failure. Refresh latency rises, redundant Git and remote-provider requests accumulate, and the server can appear frozen even though individual requests eventually complete.

Version and environment

• Fork based on upstream main at 270489b88742
• T3 Code Desktop AppImage on Arch Linux
• Same repository visible to multiple concurrent client requests

Diagnosis

The server refresh path does not share an in-flight refresh by working directory. Every caller invalidates and recomputes status independently. On the client, serial FIFO command handling preserves every queued refresh signal, so focus or visibility bursts are replayed rather than collapsed.

This is related to, but distinct from, #3581. That report covers periodic background PR polling and GitHub GraphQL quota use. This report covers overlapping explicit vcs.refreshStatus RPCs, cache invalidation, and repeated local plus remote work.

Suggested fix

• Share one in-flight explicit refresh per raw working directory on the server.
• Let that shared refresh finish if the initiating caller disconnects so other callers can still reuse it.
• Coalesce queued client refresh commands to the latest signal.
• Add regression coverage for shared results and caller interruption.

I validated this design locally: concurrent requests reuse one refresh, an interrupted first caller does not cancel it for later callers, and subsequent refreshes still run normally after completion.

Workaround

Avoid opening the same environment in multiple clients and wait for each VCS refresh before changing focus again. Restarting T3 clears the backlog but does not prevent recurrence.

Start in apps/server by tracing the vcs.refreshStatus RPC and its refresh path keyed by raw working directory, then inspect the client’s serial FIFO command handling. Add regression coverage for shared concurrent results, caller interruption, and coalesced queued refresh signals; done means one explicit refresh runs per repository and later callers reuse it without cancelling the shared work.