[Bug]: Pull Requests list is empty on GitHub Enterprise Server (GHES) because GraphQL documents include git.832008.xyz-only stack/stackEntry fields

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

Sign in to a GitHub Enterprise Server (GHES) host with gh auth login --hostname <ghes-host>.
Open a project whose remote is a repository on that GHES host.
Open the Pull Requests menu/page, or link a PR from that host to a thread.
Observe the list or summary.

Expected behavior

Pull requests from the GHES repository are listed and their summaries load. Stack data is just left out on hosts that don't support stacked PRs.

Actual behavior

The Pull Requests list is empty for GHES repositories. PR summary reads fail with
PullRequestOperationError: ... GitHub returned an unreadable getPullRequestSummary response.

Cause: PullRequestRow (used by PullRequestSearch and PullRequestList) and PullRequestSummary always contain:

stack @include(if: $stacks) { number size baseRefName }
stackEntry @include(if: $stacks) { position }

packages/source-control-github/src/server/pullRequestListings.graphql L11-20
packages/source-control-github/src/server/pullRequestBatches.graphql L47-54

@include(if: false) only skips a field at execution time. GraphQL validates the whole document against the schema first. GHES has no stack/stackEntry on PullRequest, so it rejects the query even when $stacks is false. It returns HTTP 200 with errors and no data, and T3 Code shows that as an empty list or an "unreadable" response.

Introduced by #19224, which moved these fields from string-built queries to fixed documents behind @include. Related but different fields: #17232 / #19405. Stacks REST 404 on GHES: #14458.

Suggested fix: use separate documents (or fragments chosen in code) for github.com and other hosts, so Enterprise requests never contain stack/stackEntry. PullRequestStackMembership should also only be sent to github.com.

Impact

Minor bug or occasional failure

Version or commit

0.1.1-nightly.20261016.3218

Environment

Win 11, GitHub Enterprise Server 3.21.4, T3 Code Desktop Nightly

Logs or stack traces

the `Field 'stack' doesn't exist` errors and the "unreadable getPullRequestSummary" error, with host names left out.

Screenshots, recordings, or supporting files

No response

Workaround

none in T3; currently have to view the PRs in the browser on the GHES host.

Note

Grok responding on behalf of Julius.

Confirmed on main: this is a regression from #19224, which moved the PR queries into fixed .graphql documents. Before that, stack membership was a separate query that only ran on github.com.

The code is meant to handle Enterprise Server here: $stacks is set to false off github.com, and the documents say "Enterprise Server has no pull request stacks". But @include(if: $stacks) only skips a field when the query runs. GHES checks the whole document against its schema first, so stack/stackEntry fail that check in:

pullRequestListings.graphql: the PullRequestRow fragment (L13-20), used by both search and list
pullRequestBatches.graphql: PullRequestSummary (L47-54)

PullRequestStackMembership (L68-79) has the same fields, so it should also only be sent to github.com.

Some of this overlaps with #17232 (other fields GHES doesn't support, in PR details), and #14458 covers the REST stacks endpoint. But this is a separate regression with a separate fix: stack fields need to stay out of Enterprise requests entirely. So we're keeping it open as its own bug and linking it to #17232. Thanks for tracking down the exact cause.

I can't give outside access to our GHES instance (it's a corporate server), but I verified the fix against it directly.

Environment: GitHub Enterprise Server 3.21.4, authenticated with gh auth login --hostname <ghes-host>.

I took the per-operation GraphQL documents (each operation plus only the fragments it uses, as the generated client sends them) from current main and from #20531 at 4bdb33d3e1. I sent them to a real repository with gh api graphql --hostname <ghes-host>:

Operation	`main`	#20531
`PullRequestSearch` (`stats` false and true)	❌ `Field 'stack' doesn't exist on type 'PullRequest'`, `Field 'stackEntry' doesn't exist…`, no `data`	✅ rows returned, no errors
`PullRequestList`	❌ same errors, no `data`	✅ rows returned, no errors
`PullRequestSummary`	❌ same errors, no `data`	✅ PR loaded, no errors
`PullRequestStackMembership`	❌	❌ (expected: github.com only)

This confirms the cause on a live GHES: @include(if: false) doesn't help because the server validates the whole document first. With #20531, the Enterprise list, repository-list fallback and summary queries all validate and return data. PullRequestStackMembership and the *WithStacks variants still fail on GHES, so they must stay git.832008.xyz-only, as the PR intends.

If it would help, I can also test a build of #20531 in the desktop app. I'm happy to run any other queries or builds you'd like checked.

Another confirmation, on a stable desktop build this time.

Environment

T3 Code (Beta) desktop, 0.1.3 stable, Windows 11 (x64), local server
GitHub Enterprise Server 3.21.7, gh 2.95.0 logged in with gh auth login --hostname <ghes-host> (scopes: repo, read:org)

What happens
The Pull Requests list is empty for repositories on the GHES host. listPullRequestsByHead succeeds, but getPullRequestSummary fails every time:

GitHubPullRequestReadError: GitHub returned an unreadable getPullRequestSummary response.
  [cause]: GraphQLClientError: PullRequestSummary: ResponseError:
    Field 'stack' doesn't exist on type 'PullRequest';
    Field 'stackEntry' doesn't exist on type 'PullRequest';
    Variable $_0_stacks is declared by PullRequestSummary but not used

This matches the diagnosis above. #20531 would fix it for us too.

Something that may trip up other GHES users: at first this bug was hidden behind a TLS failure. Our GHES certificate is issued by a private corporate root CA. gh trusts it through the Windows certificate store, but the T3 server (Node) doesn't use that store. Every request failed with self signed certificate in certificate chain, and the error T3 showed was just Could not reach GitHub at <ghes-host>. Pointing NODE_EXTRA_CA_CERTS at an exported copy of the root CA and fully restarting the app fixed the TLS part. Only then did the stack/stackEntry error above appear. If the error said the certificate wasn't trusted, instead of "Could not reach GitHub", this would have taken much less time to figure out. (Probably related: #16703.)

Diagnosed via t3 triage with Claude Code (Claude Opus 5.5).

Still happens on today's nightly, on macOS and an older GHES version.

Environment

T3 Code (Nightly) desktop, 0.1.5-nightly.20261029.3877 (6d450a42), macOS arm64, local server
GitHub Enterprise Server, gh logged in to the GHES host

What happens
PR summary reads fail, so the review view does not load for GHES pull requests. The server trace shows:

GitHub returned an unreadable getPullRequestSummary response
  GraphQLClientError: PullRequestSummary:
    Field 'stack' doesn't exist on type 'PullRequest'
    Field 'stackEntry' doesn't exist on type 'PullRequest'
    Variable $_0_stacks is declared by PullRequestSummary but not used

Batched summary reads fail the same way for each alias ($_1_stacks, $_2_stacks). The documents at the 3877 tag and on main still contain stack @include(if: $stacks) and stackEntry @include(if: $stacks).

The #20531 approach works on this build
I applied the same approach to a local copy of 3877: separate Enterprise documents without stack/stackEntry, with Enterprise reads routed to them. In about 35 minutes of normal use against the same GHES host, about 100 getPullRequestSummary, listPullRequests, and searchPullRequests calls all succeeded with no GraphQL schema errors. The only remaining failures were REST 404s from /repos/<owner>/<repo>/stacks, which getPullRequestStack already treats as "stacks unsupported".

#20531 currently conflicts with main.

Like the previous comment NODE_EXTRA_CA_CERTS is required.

Diagnosed via t3 triage with Claude Code (Claude Opus 5.5).

Still reproduces on v0.1.5 stable, in both T3 Code Desktop (Beta) on macOS arm64 (local server 0.1.5) and a Linux server running t3 0.1.5 linked to it. GHES host, gh authenticated with repo and read:org scopes, project remote is an SSH URL on that host.

The Pull Requests page shows none of my PRs. On the server that handles the repo, every page load logs searchPullRequests and listPullRequests failures:
GitHubApiResponseError: GitHub returned an error: Field 'stack' doesn't exist on type 'PullRequest'; Field 'stackEntry' doesn't exist on type 'PullRequest'; Variable $stacks is declared by PullRequestSearch but not used
PullRequestService.listUncached still ends in Success, so the UI shows an empty list instead of an error.
PR summary sync fails on every sweep with GitHubPullRequestReadError: GitHub returned an unreadable getPullRequestSummary response, which has the same stack/stackEntry error as its cause.
Queries without those fields work against the same host: listPullRequestsByHead, getPullRequestDetail and getPullRequestFileStats all succeed.
pullRequestListings.graphql and pullRequestBatches.graphql are unchanged on main since refactor(github): all GitHub GraphQL on effect/graphql, one request policy for REST and GraphQL #19224, so 0.1.6 nightly should also be affected.

Produced by pi coding agent (claude-opus-5.5) via T3 Code triage.

Closing: current main already covers this as of c3a36af872. If you still see it on a build that includes that commit, reply and we'll reopen.

Note

Claude Opus 5.5 is replying on my behalf.

Thanks. I think the wrong commit was linked: c3a36af is the merge of #19224, which is the commit that introduced this regression (Oct 15).

On current main (79f1fadfc6), pullRequestListings.graphql and pullRequestBatches.graphql are unchanged since c3a36af. They still contain stack @include(if: $stacks) / stackEntry @include(if: $stacks). GitHubPullRequestApi.ts still sends them to non-git.832008.xyz hosts with stacks: false.

I re-ran the per-operation documents from both c3a36af and current main against GHES 3.21.4 with gh api graphql --hostname <ghes-host>. Both fail the same way:

Operation	Result
`PullRequestSearch`	`Field 'stack' doesn't exist on type 'PullRequest'`, `Field 'stackEntry' doesn't exist…`, `Variable $stacks is declared by PullRequestSearch but not used`, no `data`
`PullRequestList`	same errors, no `data`
`PullRequestSummary`	same errors, no `data`

#20531 (still open, unmerged) fixes all three against the same host, as I posted earlier. Could you reopen this?

@felixlaga

We hit this on our GitHub Enterprise Server instance: pull request reads fail with Field 'stack' doesn't exist on type 'PullRequest'.

It is still present on current main (a21d788752). The commit cited when this was closed, c3a36af, is the merge of #19224, which introduced the regression. The listing and summary documents sent to Enterprise hosts still name stack/stackEntry behind @include(if: $stacks), and they fail validation against GitHub's published GHES 3.18–3.22 schemas.

Could this be reopened? #20531 now conflicts with main, so I've opened a smaller version on current main (crediting @felixlaga): #31184.

Still reproduces on v0.1.7 stable (server 0.1.7, Linux x64), used from the
desktop and mobile apps. The GitHub Enterprise Server host is authenticated
with gh auth login --hostname (scopes: repo, read:org). gh pr list
works fine in the same repo from the terminal.

What happens

The Pull Requests tab is empty for repos on the GHES host.
Opening and closing a PR from the app works, because that goes through gh.
The PR never appears in the tab.
Merging a PR does not settle the linked thread. The sync reactor can't read
the summary, so it never sees the merge.

Server trace (server.trace.ndjson)

GitHubPullRequestApi.searchPullRequests and listPullRequests fail with:
GitHubApiResponseError: GitHub returned an error: Field 'stack' doesn't
exist on type 'PullRequest'; Field 'stackEntry' doesn't exist on type
'PullRequest'; Variable $stacks is declared by PullRequestSearch but not
used
GitHubPullRequestApi.getPullRequestSummary fails with:
GitHubPullRequestReadError: GitHub returned an unreadable
getPullRequestSummary response, followed by PullRequestOperationError: Pull
request operation summary failed: .... That is 264 failures in the two
newest trace files.
boot-service.log has WARN pull request sync skipped with the same reason,
repeating once a minute for the linked PR.
The listPullRequestsByHead, getPullRequestDetail and getPullRequestActivity
GraphQL calls return 200 on the same host, so auth and connectivity are
fine.

This matches the diagnosis in this issue: the list and summary documents name
stack/stackEntry, and GHES rejects the whole document at validation even with
$stacks: false. The issue was closed as fixed by c3a36af, but that is the
commit that introduced the regression (#19224), and v0.1.7 still has the bug.
The fixes in #20531 and #31184 are still open. Could this be reopened?

Drafted by Claude (claude-sonnet-5-5) via Claude Code, running the T3 Code t3
triage playbook, with the user's approval.

Note

🤖 GPT-6 Astra responding with direction from Zak

Could this be reopened? The affected code is still present on current main (33f85846be).

The closing comment cites c3a36af872, but that commit is #19224, which introduced the regression. I compared both revisions: pullRequestListings.graphql and pullRequestBatches.graphql have identical Git blob IDs. The listing fragment and summary query still name stack and stackEntry under @include(if: $stacks). The caller still sends those documents to Enterprise hosts with stacks: false.

GraphQL validates field names before evaluating those directives. This source check agrees with the existing live GHES 3.21.4 verification, which reports failures on main and successful list, search, and summary queries with #20531.

I also checked #20531 at 4bdb33d3e1: its Enterprise operations omit the stack fields, while github.com uses stack-aware search and summary variants. GitHub currently reports the PR as conflicting. Could the maintainer integration noted there be resumed and the fix reviewed after updating the branch?

This is a fresh source verification, not a new live GHES or desktop-build test.

Confirmed this is still reproducible with the T3 Code 0.1.7 server on Linux x64 (Debian, kernel 6.12.113+deb13-amd64), against a GitHub Enterprise Server host. The GHES version is unknown.

The impact also extends to linked PR synchronization and automatic thread settlement:

Link an Enterprise PR to a T3 thread.
Merge the PR on GitHub Enterprise.
T3's background synchronization repeatedly fails to read its summary. In this case, even more than 10 minutes after GitHub reported the PR merged, T3 still had no saved PR state, and the thread had not automatically settled.

The local server.trace.ndjson records failures through PullRequestSyncReactor.syncGroup → PullRequestService.persistedRead → GitHubPullRequestApi.getPullRequestSummary, ending in:

GitHub returned an unreadable getPullRequestSummary response.
PullRequestSummary: ResponseError:
Field 'stack' doesn't exist on type 'PullRequest';
Field 'stackEntry' doesn't exist on type 'PullRequest'

The v0.1.7 source still includes both fields behind @include(if: $stacks) in packages/source-control-github/src/server/pullRequestBatches.graphql. A read-only API reproduction in the original investigation confirmed that the Enterprise server rejects these fields even with the condition false. Direct GitHub CLI reads succeed.

PR watching relies on the failing summary-read path, so watch registration alone cannot establish that monitoring is healthy. Automatic PR synchronization and settlement were directly observed failing; individual watch notification types were not separately tested, and watching was disabled on the example thread.

This appears to be the same compatibility issue addressed by #31184 and #20531. Please consider reopening this issue, since the failure persists in the latest stable release and affects more than the PR list.

Workaround: inspect PR state through the Enterprise website or direct GitHub CLI commands, and settle threads manually when appropriate. No local T3 patch or database changes were made during this triage.

Prepared by Codex (GPT-6) from local logs, the v0.1.7 source, and the user's referenced investigation thread.

i don't think they reopen closed issues. we might have to raise a new one.

@juliusmarminge

Closing: current main already covers this as of c3a36af872. If you still see it on a build that includes that commit, reply and we'll reopen.

@juliusmarminge Can we reopen or is new issue the way to go?

Navigation Menu

Repository navigation

[Bug]: Pull Requests list is empty on GitHub Enterprise Server (GHES) because GraphQL documents include git.832008.xyz-only `stack`/`stackEntry` fields #20436

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Pull Requests list is empty on GitHub Enterprise Server (GHES) because GraphQL documents include git.832008.xyz-only stack/stackEntry fields #20436

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Activity

juliusmarminge commented on Oct 17, 2026

Ossiam commented on Oct 22, 2026

EmanuelMedinaEme commented on Oct 28, 2026

zrm625 commented on Oct 29, 2026

pWoLiAn commented on Oct 29, 2026

juliusmarminge commented on Oct 30, 2026

Ossiam commented on Oct 31, 2026

mrmeku commented on Nov 4, 2026

seb7312 commented on Nov 6, 2026

zrm625 commented on Nov 7, 2026

zbynekwinkler commented on Nov 9, 2026

pWoLiAn commented on Nov 9, 2026

zbynekwinkler commented on Nov 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[Bug]: Pull Requests list is empty on GitHub Enterprise Server (GHES) because GraphQL documents include git.832008.xyz-only `stack`/`stackEntry` fields #20436