[Bug]: PR discovery checks hidden subagent threads every minute, so agent-heavy servers run hundreds of git lookups#26970
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Use agents that start subagents or delegates on their own branches (e.g.
delegate_task, review fan-outs). Each one becomes a child thread. - Keep inactivity settling at its default of 3 days.
- Leave
t3 serverunning with a client connected, and countrunGitCommandspans inserver.trace.ndjson.
Expected behavior
Subagent and delegate threads don't appear in the sidebar, and they are finished once their parent has the result. The per-minute PR discovery sweep should skip them, or settle them with their parent, so the git and PR lookups scale with the threads a user actually watches.
Actual behavior
ThreadPullRequestServiceV2.synchronize reads getShellSnapshot({ location: "active", unsettledOnly: true }). That query filters out settled and archived threads but not child threads, so every unsettled subagent with a branch gets a git.branchPullRequest lookup each minute (ThreadPullRequestService.ts).
On my server, agents create about 300 subagent threads a day. They only settle by inactivity after 3 days, so about 600 of them are always in the sweep. Unsettled threads, read from statev2.sqlite:
| < 1 day | 1–3 days | > 3 days | |
|---|---|---|---|
| top-level (what the sidebar shows) | 26 | 8 | 0 |
| subagent / delegate | 318 | 293 | 9 |
In about 8 minutes of server.trace.ndjson, the server ran about 3,160 git commands. About 1,900 of them came from ThreadPullRequestServiceV2.synchronize, and most of the rest from other PR or branch status reads. t3 serve sat at about 100% of one core. Shell and PR reads took up to 40 s (ws.orchestrationV2.projectShellItems up to 39 s, PullRequestSyncReactor.syncGroup up to 97 s), and remote clients dropped with SocketCloseError: 1006 and RemoteEnvironmentAuthTimeoutError ... timed out after 6000ms.
Settling the idle subagent threads by hand helps, but they aren't visible in the sidebar, so a user can't find them.
Related: #24098 (merged/closed PR threads re-read git every minute), #18618 (PR discovery rebuilds full thread shells), #26224 (event-loop freezes drop remote clients).
Impact
Major degradation or frequent failure
Version or commit
0.1.3-nightly.20261025.3669
Environment
Linux, t3 serve headless, clients over Tailscale (web + mobile). statev2.sqlite 8.7 GB.
Logs or stack traces
| 1 | Slowest span types over ~10 minutes of trace (count > 2 s, max seconds): |
| 2 | 353 36.9 lookupBranchPullRequest |
| 3 | 338 40.2 branchPullRequest |
| 4 | 337 41.6 sqlite |
| 5 | 225 97.0 PullRequestSyncReactor.syncGroup |
| 6 | 176 41.6 ProjectService.getShell |
| 7 | 165 39.2 ws.orchestrationV2.projectShellItems |
| 8 | 215 11.8 GitManager.rememberPrLookupGitState |
| 9 | |
| 10 | boot-service.log (one day): 32 VcsProcessTimeoutError (git timed out after 5000 ms), 11 LockTimeoutError. |
Screenshots, recordings, or supporting files
No response
Workaround
asking my agent to settle just the subagents