Before submitting
Area
apps/server
Steps to reproduce
- Use T3 Code Desktop with an authenticated GitHub Enterprise Server repository on a host that does not support the native pull-request stacks endpoint (observed with GHES 3.17).
- Link an ordinary, non-stacked pull request to a thread.
- Merge the pull request on the host.
- Open its PR detail panel in T3 Code and allow background PR synchronization to run.
- Compare the merged status in the detail panel with the thread's PR badge in the sidebar.
The relevant host behavior is: the normal PR read succeeds and reports merged, while the native stacks lookup returns HTTP 404. No real host, repository, or PR identifiers are needed to reproduce this behavior.
Expected behavior
The sidebar should reflect the successfully fetched merged state, and normal thread auto-settlement should be able to proceed. An unsupported optional stacks endpoint should not prevent ordinary PR status synchronization.
Actual behavior
The PR detail panel correctly shows Merged, but the sidebar keeps a gray PR badge without the merged state and the thread remains unsettled. The panel also offers Retry stack lookup. Repeated background synchronization does not resolve the mismatch.
Read-only inspection confirmed that the PR link exists, but its persisted status snapshot remains null. Direct host queries confirmed both the merged PR state and HTTP 404 from the stacks endpoint.
Investigation of the installed build points to two interacting behaviors:
- In
apps/server/src/vcs/VcsProcess.ts, classifyNonZeroExit recognizes several PR-specific not-found messages for gh, but does not classify the generic HTTP 404 response from gh api as not-found.
- Consequently, the
GitHubPullRequestNotFoundError fallback in getPullRequestStack does not handle this response.
- In the installed
PullRequestSyncReactor.syncGroup, a failed stack lookup adds the PR to retryStacks and returns before syncEntry can persist the already-successful PR summary. This leaves the sidebar snapshot empty even though the detail panel can fetch the merged state independently.
These observations are from the installed build below; this report does not claim the same control flow is present on current main.
Suggested regression coverage: a valid merged PR summary together with an unsupported stacks endpoint must still update the linked PR snapshot. Distinguish an unsupported endpoint from authentication, rate-limit, and transient failures rather than treating every stack error as an empty stack.
Impact
Minor bug or occasional failure
For affected hosts, repeated synchronization leaves linked PR statuses inaccurate and prevents the expected merge-based thread settlement, although PR details remain accessible.
Version or commit
0.0.45-nightly.20260930.2481
Installed build commit: c18e5ea
Environment
macOS 27.0, T3 Code Desktop Nightly; GitHub Enterprise Server 3.17. Authentication and ordinary PR reads succeed.
Logs or stack traces
Omitted for privacy. No logs, screenshots, private URLs, repository names, account details, or local paths are attached.
Screenshots, recordings, or supporting files
None.
Workaround
No verified workaround for automatic sidebar synchronization. The PR detail panel can still be used to check the actual merge state. No settings or application data were changed during diagnosis.
Before submitting
Area
apps/server
Steps to reproduce
The relevant host behavior is: the normal PR read succeeds and reports merged, while the native stacks lookup returns HTTP 404. No real host, repository, or PR identifiers are needed to reproduce this behavior.
Expected behavior
The sidebar should reflect the successfully fetched merged state, and normal thread auto-settlement should be able to proceed. An unsupported optional stacks endpoint should not prevent ordinary PR status synchronization.
Actual behavior
The PR detail panel correctly shows Merged, but the sidebar keeps a gray PR badge without the merged state and the thread remains unsettled. The panel also offers Retry stack lookup. Repeated background synchronization does not resolve the mismatch.
Read-only inspection confirmed that the PR link exists, but its persisted status snapshot remains null. Direct host queries confirmed both the merged PR state and HTTP 404 from the stacks endpoint.
Investigation of the installed build points to two interacting behaviors:
apps/server/src/vcs/VcsProcess.ts,classifyNonZeroExitrecognizes several PR-specific not-found messages forgh, but does not classify the generic HTTP 404 response fromgh apias not-found.GitHubPullRequestNotFoundErrorfallback ingetPullRequestStackdoes not handle this response.PullRequestSyncReactor.syncGroup, a failed stack lookup adds the PR toretryStacksand returns beforesyncEntrycan persist the already-successful PR summary. This leaves the sidebar snapshot empty even though the detail panel can fetch the merged state independently.These observations are from the installed build below; this report does not claim the same control flow is present on current main.
Suggested regression coverage: a valid merged PR summary together with an unsupported stacks endpoint must still update the linked PR snapshot. Distinguish an unsupported endpoint from authentication, rate-limit, and transient failures rather than treating every stack error as an empty stack.
Impact
Minor bug or occasional failure
For affected hosts, repeated synchronization leaves linked PR statuses inaccurate and prevents the expected merge-based thread settlement, although PR details remain accessible.
Version or commit
0.0.45-nightly.20260930.2481
Installed build commit: c18e5ea
Environment
macOS 27.0, T3 Code Desktop Nightly; GitHub Enterprise Server 3.17. Authentication and ordinary PR reads succeed.
Logs or stack traces
Omitted for privacy. No logs, screenshots, private URLs, repository names, account details, or local paths are attached.
Screenshots, recordings, or supporting files
None.
Workaround
No verified workaround for automatic sidebar synchronization. The PR detail panel can still be used to check the actual merge state. No settings or application data were changed during diagnosis.