Sign up
View stargazersSign up

Show pull requests as Queued when they enter GitHub's merge queue#12499

openedSep 18, 2026byYyuriharrison

Problem

When a linked pull request is approved and then added to GitHub's merge queue, T3 Code continues to display its status as Approved. GitHub displays the pull request as Queued, so T3 Code's status is stale and makes it look as though the merge action has not taken effect.

Expected behavior

T3 Code should recognize GitHub's merge-queue state and display a yellow Queued status for the linked pull request. Once GitHub merges the pull request, T3 Code should transition it to Merged as usual.

Steps to reproduce

  1. Link a pull request to a T3 Code thread.
  2. Obtain the required approval and passing checks.
  3. Add the pull request to GitHub's merge queue.
  4. Observe that GitHub reports Queued while T3 Code still reports Approved.

Why this matters

The current status does not distinguish an approved pull request awaiting action from one already accepted into the merge queue.

JJulius MarmingeSep 18, 2026

Thanks for the clear report — this is a real gap, not a stale refresh of an existing field.

T3 does not have a merge-queue state, so a PR that GitHub shows as Queued keeps looking Approved here.

What T3 actually shows

Linked-PR status is built from host snapshot fields that stop at lifecycle + review + checks:

  • PullRequestState is only open | closed | merged, with draft overlaid (packages/contracts/src/pullRequest.ts)
  • ThreadPullRequestSnapshot persists state, isDraft, reviewDecision, checksState, and mergeability — nothing for queue membership (packages/contracts/src/orchestration.ts)
  • The thread “Approved” glyph is the review verdict, shown whenever an open snapshot has reviewDecision === "approved" (apps/web/src/components/pullRequest/ThreadPullRequestsPanel.tsx)
  • Sidebar / composer badges use resolvePullRequestState() and can only render Open / Draft / Closed / Merged (apps/web/src/components/pullRequest/pullRequestIcons.tsx, apps/web/src/components/ThreadStatusIndicators.tsx)

GitHub’s fetch path never asks for queue membership either. List and detail queries request state, isDraft, mergeable, reviewDecision, checks, and autoMergeRequest — not isInMergeQueue / mergeQueueEntry (apps/server/src/pullRequest/gitHubPullRequestJson.ts). The sync reactor copies only those summary fields onto the thread snapshot (apps/server/src/orchestration/PullRequestSyncReactor.ts).

So after a PR is approved and then added to the merge queue:

  • GitHub: still OPEN, still reviewDecision: APPROVED, and isInMergeQueue: true → UI says Queued
  • T3: still open + approved → UI says Approved / Open
  • Once GitHub merges it, T3 already has state: "merged" and can show Merged as today

autoMergeEnabled is a different thing. It exists on detail (the armed auto-merge control) and is not on the thread snapshot, so it cannot substitute for a yellow Queued badge on a linked PR.

The product already knows enqueue can happen — stack merge treats GitHub’s enqueued response as success and toasts “merged the stack or added it to its merge queue” (apps/server/src/pullRequest/githubStackActions.ts, apps/web/src/components/pullRequest/PullRequestStackMenu.tsx) — but that does not change the displayed status.

Not a duplicate

I did not find an existing issue or Ideas discussion that asks for a Queued merge-queue status on linked PRs. Nearby “queued” threads are about composer/outbox messages, not GitHub’s merge queue.

Suggested shape (if we take this)

This is a small, GitHub-only model addition rather than a general status rewrite:

  1. Optional inMergeQueue (or equivalent) on PullRequestSummary, ThreadPullRequestSnapshot, list rows, and detail
  2. Request GitHub isInMergeQueue (and maybe mergeQueueEntry.state) on the existing list + detail reads
  3. Prefer Queued (amber/yellow) over Open + Approved on the linked-PR surfaces: thread panel, list row, sidebar/composer badge, detail header
  4. Leave other hosts unset; they have no merge queue
  5. Keep Merged as the terminal state after GitHub completes the queue

CONTRIBUTING.md still prefers Ideas discussions for net-new product work. This one is tightly scoped to an existing PR-status surface, and T3 already enqueues into merge queues, so keeping it as an issue looks reasonable.

I have not changed code or opened a PR.

This conversation has been locked.