Required status check added via ruleset gets permanently stuck as "Expected" on pre-existing open PRs, with no in-UI way to resolve it

[gloomydumber]

🏷️ Discussion Type

Product Feedback

Body

Summary

When an organization adds a new required status check to a branch ruleset (or classic branch protection), the requirement applies retroactively to all open PRs already targeting that branch. Any open PR whose head branch predates the producing workflow (or whose workflow emits a different check context name) can never satisfy the new requirement, because a required check is only marked satisfied when a workflow runs on that PR's head commit and reports that exact context. If the head branch does not contain the workflow file, nothing ever reports the context. The PR then shows the check as Required with the status "Expected, Waiting for status to be reported" indefinitely, with no button to run or re-run it (there is no run to re-run) and no guidance on how to clear it.

Environment

Plan: GitHub Team. Feature: branch rulesets (and classic branch protection) with required status checks. Repo settings at defaults: allow_update_branch = false and strict required status checks = false.

Steps to reproduce

1. Create a repo with a default branch (main).
2. Open a PR from a feature branch created before any CI workflow existed on the base branch; confirm it can merge.
3. On the base branch, add an Actions workflow that produces a status check with a specific context name (for example a job named "build").
4. Create or edit a branch ruleset targeting the default branch and mark that context ("build") as Required.
5. Leave repo settings at defaults (allow_update_branch off, strict checks off).
6. Return to the PR from step 2 and view the merge box.

Observed behavior

• The required check shows as "Expected, Waiting for status to be reported" and never resolves, because the PR head commit does not contain the workflow and nothing reports that context.
• There is no button to trigger or re-run it.
• Because allow_update_branch and strict checks are both off (defaults), GitHub does not show the "Update branch" button, which is the only action that would pull the workflow in and let the check run.
• No explanation is shown for why the check is stuck. The PR is effectively blocked with no in-UI path forward.

Expected / kinder behavior

When a required check has never been reported on a PR AND the branch is behind base (and/or lacks the producing workflow), detect this and surface, in the merge box, an "Update branch to run required checks" action plus a one-line reason, even when allow_update_branch is off and checks are non-strict. At minimum, explain why the check is "Expected" and how to resolve it, instead of an indefinite silent wait.

Impact

This happens every time an org introduces a new required check on an active repo with open PRs, which is a common hardening step. Each affected PR becomes unmergeable with no self-service remedy; the workaround (rebase/update each branch from the CLI, or toggle repo settings) is non-obvious and invisible to the PR author.

Suggested improvement

Detect the "required check never reported + branch behind base and/or missing producing workflow" state and surface a clear "Update branch to run required checks" affordance with a one-line reason, independent of the allow_update_branch and strict-checks settings; or at least show the reason and resolution steps.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[aniketatgithub]

A required check only counts when it is reported against the pull request's latest head commit, and in your repro nothing can ever report it: the workflow file is not part of the head commit, so the run that would produce the build context never happens.

The way out is to give the head commit a chance to run the workflow:

1. Update the PR branch with the latest base branch (merge main into the branch and push, or use Update branch where it is offered), so the workflow file is part of the head commit.
2. Push. That triggers the workflow, it reports the build context on the new head SHA, and the Expected state clears.

Two related points from the docs: required checks must pass on the latest commit SHA, results from older commits do not carry over; and checks only satisfy a ruleset when the run is triggered by an eligible event such as pull_request or push, not workflow_dispatch.

An admin can bypass the ruleset once to unblock a specific PR, but update-and-push is what fixes it permanently for that PR.

[gloomydumber]

Thanks for the reply, though I was already aware of the mechanism and the branch-update / admin-bypass workaround. To clarify the ask: this request is about the UX, not the mechanism. When a required check has never reported and the branch is behind (and/or lacks the workflow), GitHub should surface an "Update branch to run required checks" action and a one-line reason in the merge box, even with allow_update_branch off and non-strict checks. Right now it shows an indefinite "Expected" with no button and no explanation, which is the dead-end for the PR author.