devActivitydevActivity Logo

Achieving Software Development Goals: The Call for Consistent Merged PR Review Behavior

Visualizing the divergence between GitHub's Web UI and API behavior for merged pull requests.
Visualizing the divergence between GitHub's Web UI and API behavior for merged pull requests.

The GitHub API & UI Divide: Merged PR Reviews

A recent GitHub Community discussion, initiated by davidxia, highlighted a significant inconsistency causing confusion among developers and maintainers: the ability to review merged Pull Requests (PRs). While the GitHub Web UI explicitly prevents submitting reviews on PRs once they are merged, the GitHub API currently allows this action. This divergence creates a challenging scenario for tools like the gh CLI, which relies on the API and thus inherits this behavior.

The original post referenced an issue in the gh CLI repository (cli/cli#5038), where the team acknowledged the problem but deemed it a platform-level concern rather than a CLI-specific bug. The core issue isn't just about a technical discrepancy; it impacts developer workflows, automation, and overall trust in the platform's consistency, directly affecting teams striving to meet their software development goals efficiently.

Streamlined development workflow achieved through consistent platform behavior, supporting software development goals.
Streamlined development workflow achieved through consistent platform behavior, supporting software development goals.

Why Consistency Matters for Software Development Goals

The Problem of Inconsistency

Community members quickly echoed the sentiment that this inconsistency is a genuine pain point. KaweMaximo articulated several critical problems arising from this behavior:

  • Automation Clutter: Bots and automation tools can inadvertently submit reviews on merged PRs via the API, leading to cluttered notification feeds and confusion for contributors.
  • Tooling Overhead: CI/CD pipelines and GitHub Apps designed to mirror Web UI behavior must implement their own protective guards, adding unnecessary complexity.
  • Erosion of Trust: Such divergent behavior can erode trust in the API as a reliable contract, particularly when its actions contradict the Web UI's enforced constraints.

The discussion also touched upon the concern that allowing reviews on merged PRs could be exploited as a 'spam vector,' similar to how comments can be used on resolved issues.

Proposed Resolution: API Parity with UI

To address these issues and foster more predictable software engineering goals, KaweMaximo proposed a clear resolution: the API should align with the Web UI. Specifically, the API should return a 422 Unprocessable Entity (or similar) when a review is attempted on a merged or closed PR. A clear error message would make the intent explicit:

"Reviews cannot be submitted on merged pull requests"

For any consumers currently relying on the API's existing behavior, a deprecation notice and a grace period would be essential to facilitate a smooth transition.

Navigating Spam & Workflow Considerations

While consistency is a strong argument, the discussion also acknowledged the nuances. shivrajcodez pointed out that even if reviews were blocked, maintainers would still need moderation tools for spam, as comments can still be posted on merged PRs. Effective mitigation often involves repository-level controls such as locking the PR, enabling moderation limits, or using automation to detect spam patterns.

Furthermore, shivrajcodez noted that there could be legitimate use cases for post-merge reviews, such as retroactive code audits, training feedback, or adding audit notes. Any change to the API would need careful consideration to avoid disrupting workflows that depend on this current capability.

The Path Forward: Platform-Level Engagement

There was a strong consensus among contributors, including ash-iiiiish and shivrajcodez, that this is fundamentally a platform-level API behavior issue, not a problem for individual clients to solve. The recommended path forward is to discuss this in the official GitHub feedback forum for Pull Requests (https://github.com/github/feedback/discussions/categories/pull-requests-feedback). This ensures the GitHub platform team can evaluate whether the API and UI should behave consistently, weighing the benefits of consistency against potential impacts on existing workflows.

Ultimately, achieving a unified and predictable experience across GitHub's Web UI and API is crucial for enhancing developer productivity and effectively supporting broader software development goals within the community.