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>
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