Skip to content

feat(issues): Expose mergeable_state on group pull requests#120170

Draft
jshchnz wants to merge 1 commit into
masterfrom
jc-group-prs-mergeable-state
Draft

feat(issues): Expose mergeable_state on group pull requests#120170
jshchnz wants to merge 1 commit into
masterfrom
jc-group-prs-mergeable-state

Conversation

@jshchnz

@jshchnz jshchnz commented Jul 21, 2026

Copy link
Copy Markdown
Member

Adds mergeableState to the group pull-requests endpoint (/issues/{id}/pull-requests/) so the UI can tell whether a linked PR is actually ready to squash-and-merge or blocked.

What

  • The endpoint already calls client.get_pull_request() as a status fallback and discarded the merge-readiness fields in the response. Those fields are now parsed: mergeableState is GitHub's mergeable_state, lowercased — clean (ready to merge), unstable (checks failing but mergeable), blocked (required checks/reviews outstanding), dirty (conflicts), behind (needs rebase) — with unrecognized values collapsing to unknown and null for terminal PRs or when the provider is unavailable.
  • Behavior change: open/draft PRs now always consult the provider (previously only when no stored status existed), since the stored row can't answer merge readiness. Terminal PRs (merged/closed) still answer from the webhook-kept stored fields with no round-trip. Provider failures fall back to the stored status as before.
  • The provider lookup gains a short-lived cache (120s, keyed by integration + PR id) so a page of cards doesn't spend GitHub rate limit per re-render; mergeability flips as checks finish, so the TTL stays short.
  • LinkedPullRequestResponse gains the typed field; LinkedPullRequestSerializer takes the new mapping as an optional keyword, so other callers are unaffected.

Why

The Seer Autofix overview (#120163) shows runs whose last step is "review and merge the PR" — a merge-readiness badge next to the PR link needs this field. Frontend consumption lands separately once this deploys.

🤖 Generated with Claude Code

The endpoint already fetches the provider PR as a status fallback and
discarded its merge-readiness fields. Now open PRs always consult the
provider (behind a short-lived cache) and the response gains
mergeableState — GitHub's clean/unstable/blocked/dirty/behind,
normalized, unknown for unrecognized values, null for terminal PRs or
when the provider is unavailable. Stored lifecycle fields still answer
merged/closed without a round-trip and back the status up when the
provider fetch fails.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@github-actions github-actions Bot added the Scope: Backend Automatically applied to PRs that change backend components label Jul 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant