| … | … | @@ -152,7 +156,7 @@ function PullRequestRowImpl({ | |
| 153 | 157 | {/* Only a verdict somebody has actually given: "review required" is the absence of | |
| 154 | 158 | one, and saying so on every unreviewed row would say nothing. */} | |
| 155 | - | {entry.reviewDecision === "approved" ? ( | |
| 159 | + | {entry.inMergeQueue ? null : entry.reviewDecision === "approved" ? ( | |
🟡 Medium pullRequest/PullRequestRow.tsx:159
Closed or merged rows lose their Approved/Changes requested indicator when stale inMergeQueue metadata is present. This unconditional suppression disagrees with the terminal-state handling in the state glyph; restrict it to open queued PRs so terminal rows retain their review verdict.
| 1 | {entry.inMergeQueue && entry.state === "open" ? null : entry.reviewDecision === "approved" ? ( |
🤖 Copy this AI Prompt to have your agent fix this:
| 1 | In file @apps/web/src/components/pullRequest/PullRequestRow.tsx around line 159: |
| 2 | |
| 3 | Closed or merged rows lose their `Approved`/`Changes requested` indicator when stale `inMergeQueue` metadata is present. This unconditional suppression disagrees with the terminal-state handling in the state glyph; restrict it to open queued PRs so terminal rows retain their review verdict. |
Addressed
Sorry, I'm unable to act on this request because you do not have permissions within this repository.
| … | … | @@ -1556,6 +1625,7 @@ function toListItem(raw: Schema.Schema.Type<typeof RawListItemSchema>): GitHubPu | |
| 1556 | 1625 | baseBranch: raw.baseRefName, | |
| 1557 | 1626 | state: toState(raw), | |
| 1558 | 1627 | isDraft: raw.isDraft ?? false, | |
| 1628 | + | ...(raw.isInMergeQueue === true ? { inMergeQueue: true } : {}), | |
🟡 Medium pullRequest/gitHubPullRequestJson.ts:1628
Queued PRs are never marked inMergeQueue in the normal gh pr list path, so listings present them as Open/Approved instead of Queued. GitHubPullRequestCli passes PULL_REQUEST_LIST_JSON_FIELDS to gh pr list, but that field list omits isInMergeQueue, leaving raw.isInMergeQueue undefined and making this condition false. Add isInMergeQueue to the CLI JSON fields, with the required compatibility handling.
🤖 Copy this AI Prompt to have your agent fix this:
| 1 | In file @apps/server/src/pullRequest/gitHubPullRequestJson.ts around line 1628: |
| 2 | |
| 3 | Queued PRs are never marked `inMergeQueue` in the normal `gh pr list` path, so listings present them as Open/Approved instead of Queued. `GitHubPullRequestCli` passes `PULL_REQUEST_LIST_JSON_FIELDS` to `gh pr list`, but that field list omits `isInMergeQueue`, leaving `raw.isInMergeQueue` `undefined` and making this condition false. Add `isInMergeQueue` to the CLI JSON fields, with the required compatibility handling. |
false positive
Sorry, I'm unable to act on this request because you do not have permissions within this repository.
| … | … | @@ -2879,6 +2886,7 @@ export const make = Effect.gen(function* () { | |
| 2879 | 2886 | url: detail.url, | |
| 2880 | 2887 | state: detail.state, | |
| 2881 | 2888 | isDraft: detail.isDraft, | |
| 2889 | + | ...(detail.inMergeQueue === undefined ? {} : { inMergeQueue: detail.inMergeQueue }), | |
🟡 Medium pullRequest/PullRequestService.ts:2889
A detail refresh after GitHub reports a PR leaving the merge queue keeps the held summary's inMergeQueue as true, so the UI continues to mark the PR as queued until another summary or list read overwrites it. Because summaryFromDetail starts with ...previous and omits inMergeQueue when detail.inMergeQueue is undefined, the stale inherited value survives; assign the field explicitly so the refresh clears it.
| 1 | - ...(detail.inMergeQueue === undefined ? {} : { inMergeQueue: detail.inMergeQueue }), |
| 2 | + inMergeQueue: detail.inMergeQueue, |
🤖 Copy this AI Prompt to have your agent fix this:
| 1 | In file @apps/server/src/pullRequest/PullRequestService.ts around line 2889: |
| 2 | |
| 3 | A detail refresh after GitHub reports a PR leaving the merge queue keeps the held summary's `inMergeQueue` as `true`, so the UI continues to mark the PR as queued until another summary or list read overwrites it. Because `summaryFromDetail` starts with `...previous` and omits `inMergeQueue` when `detail.inMergeQueue` is `undefined`, the stale inherited value survives; assign the field explicitly so the refresh clears it. |
Addressed
Sorry, I'm unable to act on this request because you do not have permissions within this repository.
| … | … | @@ -1933,56 +1939,40 @@ export const make = Effect.gen(function* () { | |
| 1949 | + | ["-f", `name=${parseRepositorySelector(input.repository).name}`], | |
| 1950 | + | ["-F", `number=${input.number}`], | |
| 1951 | + | ], | |
| 1952 | + | query: pullRequestSummaryGraphQlQuery(input.host === "github.com"), | |
🟡 Medium pullRequest/GitHubPullRequestCli.ts:1952
getPullRequestSummary reports a PR as passing when its first 100 check contexts pass, even if a later check is failing or pending. pullRequestSummaryGraphQlQuery does not request pagination metadata, and decodePullRequestSummaryJson therefore computes checksState from a truncated contexts(first: 100) array; use a complete rollup or fall back to the paginated gh pr view path when more contexts exist.
Also found in 1 other location(s)
apps/server/src/pullRequest/gitHubPullRequestJson.ts:789
The new summary query reads only the first 100
statusCheckRollup.contextsand does not requestpageInfoor otherwise account for truncation.decodePullRequestSummaryJsonfeeds that partial array torollupChecksState, which returnspassingwhen the returned checks are successful. Thus a PR with (for example) 100 successful contexts followed by a failing/pending one is reported as passing in summary surfaces; the priorgh pr viewpath paged its rollup (as the detail fallback comment notes). Request/use a complete rollup or treathasNextPageas an unknown/non-passing summary state.
🤖 Copy this AI Prompt to have your agent fix this:
| 1 | In file @apps/server/src/pullRequest/GitHubPullRequestCli.ts around line 1952: |
| 2 | |
| 3 | `getPullRequestSummary` reports a PR as passing when its first 100 check contexts pass, even if a later check is failing or pending. `pullRequestSummaryGraphQlQuery` does not request pagination metadata, and `decodePullRequestSummaryJson` therefore computes `checksState` from a truncated `contexts(first: 100)` array; use a complete rollup or fall back to the paginated `gh pr view` path when more contexts exist. |
| 4 | |
| 5 | Also found in 1 other location(s): |
| 6 | - apps/server/src/pullRequest/gitHubPullRequestJson.ts:789 -- The new summary query reads only the first 100 `statusCheckRollup.contexts` and does not request `pageInfo` or otherwise account for truncation. `decodePullRequestSummaryJson` feeds that partial array to `rollupChecksState`, which returns `passing` when the returned checks are successful. Thus a PR with (for example) 100 successful contexts followed by a failing/pending one is reported as passing in summary surfaces; the prior `gh pr view` path paged its rollup (as the detail fallback comment notes). Request/use a complete rollup or treat `hasNextPage` as an unknown/non-passing summary state. |
Addressed
Sorry, I'm unable to act on this request because you do not have permissions within this repository.
🟡 Medium
Queued rows still render PullRequestChecksPopover, so an open PR in the merge queue shows a normal passing or failing check verdict alongside the queued lifecycle status. Gate this condition on entry.inMergeQueue so queue state takes precedence; apply the same suppression to the linked-thread row.
🤖 Copy this AI Prompt to have your agent fix this:
| 1 | In file @apps/web/src/components/pullRequest/PullRequestRow.tsx around line 166: |
| 2 | |
| 3 | Queued rows still render `PullRequestChecksPopover`, so an open PR in the merge queue shows a normal passing or failing check verdict alongside the queued lifecycle status. Gate this condition on `entry.inMergeQueue` so queue state takes precedence; apply the same suppression to the linked-thread row. |
Addressed
