[Bug]: PullRequestSyncReactor's gh calls fail with an opaque error — VcsProcessExitError discards stderr, so the real cause can't be diagnosed #12224

Activity

1. juliusmarminge commented on Sep 17, 2026

   

   juliusmarminge

   on Sep 17, 2026

   Member

   More actions

   Triage

   Confirmed on current main (0150c6a53). Real server GitHub CLI bug on packaged desktop. Not a duplicate of #11220 (cadence) or #11247 (App installation token). The gh ($HOME) string is real; the command that produces it is not the pr view the reactor thinks it is running.

   What happens

   Packaged desktop starts the backend with cwd = the user’s home directory:

       backendCwd: input.isPackaged ? homeDirectory : appRoot,

   PullRequestSyncReactor.syncGroup then calls pullRequests.summary with recoverTransientFailure: false every time an open, unsettled link is due (the 1-minute sweep from Schedule.spaced("1 minute")):

       const syncGroup = Effect.fn("PullRequestSyncReactor.syncGroup")(function* (
         key: string,
         entries: ReadonlyArray<LinkEntry>,
       ) {
         // ...
         const summary = yield* pullRequests.summary(ref, { recoverTransientFailure: false });

   summaryUncached does pass the project root into the provider:

     const summaryUncached: PullRequestService["Service"]["summary"] = (input) =>
       requireProject(input).pipe(
         Effect.flatMap((project) => {
           const providerInput = {
             cwd: project.project.workspaceRoot,
             repository: project.repository,
             host: project.host,
             number: input.number,
           };
           const read =
             project.api.getChangeRequestSummary === undefined
               ? project.api.getChangeRequest(providerInput)
               : project.api.getChangeRequestSummary(providerInput);

   and getPullRequestSummary runs gh pr view <n> --repo <host>/<repo>, which does not need a local git checkout:

       getPullRequestSummary: (input) =>
         github
           .execute({
             cwd: input.cwd,
             args: [
               "pr",
               "view",
               String(input.number),
               ...repositoryArgs(input),
               "--json",
               PULL_REQUEST_DETAIL_JSON_FIELDS,
             ],
           })

   That execute never reaches pr view until a quota probe succeeds. Since #11888 the probe is hardcoded to the server cwd:

     const quota = yield* Cache.makeWith(
       (key: string) => {
         const host = key.split("\0")[0]!;
         return executeRaw({
           cwd: globalThis.process.cwd(),
           args: [
             "api",
             "rate_limit",
             "--hostname",
             host,
             "--jq",
             ".resources.graphql | {data:{rateLimit:{cost:1,limit:.limit,remaining:.remaining,resetAt:(.reset|todateiso8601)}}}",
           ],
         }).pipe(
           // ...
         );
       },
       {
         capacity: 32,
         timeToLive: (exit) => (Exit.isSuccess(exit) ? Duration.seconds(30) : Duration.zero),
       },
     );
     // pr list | pr view | repo view then:
     yield* Cache.get(quota, `${host}\0${credential?.credentialFingerprint ?? ""}`);
     return yield* executeRaw(input);

   VcsProcessExitError prints gh (<cwd>). That is why every failure shows gh (/Users/ryan) — it is process.cwd(), which packaged desktop set to $HOME. A failed probe is not cached (timeToLive is 0 on failure), so every sweep retries it and pr view never runs. recoverTransientFailure: false also drops any last-good summary.

   The pasted stack does not include gh stderr. VcsProcessExitError.detail is only Process exited with a non-zero status. The cd ~ && gh pr list --json number repro is a different command (pr list with no --repo). T3’s actual read is pr view --repo. The command that matches cwd=$HOME on every failure is the quota gh api rate_limit.

   ThreadPullRequestReactor is the contrast: it picks worktree or project.workspaceRoot before calling git/gh. The sync reactor never sets cwd itself; GitHubCli.execute overwrites it for the probe.

   Nightly 0.0.43-nightly.20260917.1837 includes #11888 (merged 2026-09-15). Auth is fine; this is not #11247.

   Not a duplicate

   • Thread PR discovery and settlement sweeps run every minute without client demand, and their caches expire before the next sweep #11220 — same 1-minute sweep, about spawn volume / cache TTL, not wrong cwd.
   • [Bug]: Pull Requests page fails with "GitHub CLI command failed" when gh uses a GitHub App installation token #11247 — gh api user 403 on an App installation token. Reporter already ruled that out (personal OAuth).
   • [Bug]: Git dir followed unconditionally #12204 — wrong project root via separate git-dir. Different path.

   No existing issue for the quota probe using process.cwd().

   Likely code

   • apps/server/src/sourceControl/GitHubCli.ts — probe cwd is process.cwd(); failure blocks pr view / pr list / repo view.
   • apps/desktop/src/app/DesktopEnvironment.ts — packaged backendCwd is $HOME.
   • apps/server/src/pullRequest/GitHubPullRequestCli.ts — real read already has project cwd + --repo.
   • apps/server/src/orchestration/PullRequestSyncReactor.ts
   • packages/contracts/src/vcs.ts — gh (<cwd>) in the message.

   Fix direction

   1. Pass input.cwd (already the project workspace root) into the quota executeRaw, not process.cwd().
   2. Do not fail the real pr view when the probe fails. Treat a dead probe as “unknown budget” and still run the read. A host-level rate_limit should not take the PR sync path down.
   3. Test: packaged-style process.cwd() === $HOME (not a git repo) + execute({ cwd: "/repo", args: ["pr", "view", …] }) must still call pr view with /repo. Cover probe-failure-must-not-block-read.
   4. If a follow-up log still has stderr not a git repository on pr view --repo itself, then also check workspaceRoot; that is a second bug, not what this stack shows.

   Workaround

   None in the UI. Unpacked / npx t3 serve from a repo may hide it because process.cwd() is then a git root. No user setting points the probe at the project.

   Accepting as a server GitHub CLI bug. The reactor cadence in #11220 makes the failed probe loud; it is not the cause.
2. Artic0din commented on Sep 17, 2026

   

   Artic0din

   on Sep 17, 2026

   Last edited by Artic0din

   Author

   More actions

   Correction

   I traced the exact code path (PullRequestSyncReactor.syncGroup → PullRequestService.summary → requireProject → getChangeRequestSummary → GitHubPullRequestCli.getPullRequestSummary) in the actual source rather than guessing from the packaged trace alone.

   getPullRequestSummary always passes --repo <host>/<repository> explicitly:

   github.execute({
     cwd: input.cwd,
     args: ["pr", "view", String(input.number), ...repositoryArgs(input), "--json", ...],
   })

   gh pr view --repo owner/repo does not require cwd to be inside a git repository. I confirmed this directly:

   $ cd /Users/ryan && gh pr view 11225 --repo pingdotgg/t3code --json number,title
   {"number":11225,"title":"fix(cursor): retry prompts that only returned a transport failure"}
   

   Exit 0, from the bare home directory. So "not a git repository" is not what's failing these calls — retracting that part of the original report. cwd really is project.workspaceRoot for the pr view call itself (confirmed via requireProject), it just isn't the cause of that call failing.

   I couldn't find the actual failing call site from the trace alone, since VcsProcessExitError only keeps stderrLength, not the text. See the triage comment below — the real mechanism is the gh api rate_limit quota probe inside GitHubCli.execute, which does hardcode process.cwd() rather than input.cwd. That's the actual cwd bug; it's just one call earlier in the chain than I looked.
3. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   acceptedfeature request acceptedfeature request accepted

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Sep 17, 2026
4. Artic0din

   changed the title [-][Bug]: PullRequestSyncReactor runs gh with server cwd ($HOME) instead of project root, failing every sync sweep[/-] [+][Bug]: PullRequestSyncReactor's gh calls fail with an opaque error — VcsProcessExitError discards stderr, so the real cause can't be diagnosed[/+] on Sep 17, 2026
5. josephv123 commented on Oct 6, 2026

   

   josephv123

   on Oct 6, 2026

   More actions

   The blocking part of this appears fixed on main by #14673.

   The probe that failed with gh (<home>) was gh api rate_limit with process.cwd(). #14673 replaced it with a GraphQL rateLimit reading (budgetReading in apps/server/src/sourceControl/GitHubCli.ts), and guardedRead now ignores a failed reading: Cache.get(budgetReading, …).pipe(Effect.ignore), commented "A failed reading leaves the budget unknown; it never blocks the read itself." That's fix direction 2 from the triage, so pr view --repo runs even when the reading fails. The reading still runs from process.cwd(), but gh api graphql --hostname doesn't need a git checkout.

   What remains is the title's point that VcsProcessExitError doesn't include stderr. That's a contract-level choice, so it may be worth its own issue if wanted. Otherwise this one can probably be closed.
6. juliusmarminge commented on Oct 6, 2026

   

   juliusmarminge

   on Oct 6, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Resolved by the GitHub API stack that landed today (#16319, #16320, #16321). Pull request sync no longer shells out to gh; it calls GitHub's API in-process, and GitHubCli.execute is gone, so the opaque VcsProcessExitError from those calls can't happen anymore. API failures now map to specific reasons (unauthenticated, rate-limited with a retry time, not found). Closing; open a new issue with the new error if PR sync still fails.
7. juliusmarminge

   closed this as completedon Oct 6, 2026