Pull Request #88 remains OPEN despite its merge commit being integrated into the base branch during GitHub's November 4, 2026 incident

[ladenexpert]

🏷️ Discussion Type

Bug

Body

Hello GitHub Community,

I'm reporting a persistent pull request lifecycle inconsistency that occurred during the GitHub service incident on November 4, 2026, affecting Pull Requests, Git Operations, Issues, API Requests, and Actions.

The underlying Git repository has been successfully updated, but GitHub still reports the pull request as OPEN and unmerged.

I would appreciate assistance in determining whether this is related to the service incident and how to safely reconcile the pull request metadata without modifying the existing Git history.

1. Repository and pull request

• Repository: ladenexpert/inventory-management-system
• Pull request: https://github.com/ladenexpert/inventory-management-system/pull/88
• PR title: docs(v0.7.0): record WP8 final closure
• Base branch: develop/v0.7.0-inventory-expansion
• Head branch: docs/v0.7.0-wp8-final-closure
• PR head SHA: da42bd74d57e6a2d93e410b3d52965191e14db4f
• Original base SHA: 232f19fa622700bdba43eb40b992256f63460bf5
• Current base HEAD: e844e9bc197bcdf1880dadba44e4369adcd74783

The PR contains only four Markdown documentation changes (+193/-4 lines), with no application code or database changes.

2. Exact timeline and GitHub incident overlap

All timestamps below are in UTC.

Official status history:
https://www.githubstatus.com/history
Incident title: Incident with Pull Requests, Git Operations and Issues
The PR creation and merge commit both occurred during the documented incident window of 09:49–11:50 UTC.

This timing suggests a possible relationship with the incident, but I cannot independently establish causation.

3. Evidence that the Git changes are already integrated

The current base branch points to: e844e9bc197bcdf1880dadba44e4369adcd74783

Commit: https://github.com/ladenexpert/inventory-management-system/commit/e844e9bc197bcdf1880dadba44e4369adcd74783

Commit message: Merge pull request #88 from ladenexpert/docs/v0.7.0-wp8-final-closure

The commit has exactly two parents:

• 232f19fa622700bdba43eb40b992256f63460bf5 — original base commit
• da42bd74d57e6a2d93e410b3d52965191e14db4f — exact PR #88 head commit

GitHub's comparison confirms that the PR head is already an ancestor of the current base branch. No outstanding file differences remain between the integrated documentation changes and develop. The local repository was also fast-forwarded successfully to e844e9bc, and the working tree is clean.
The temporary local documentation branch was safely deleted. The remote documentation branch remains available.

4. Actual GitHub API and UI behavior
   Despite the above Git commit evidence, the Pull Requests API still reports:
   {
   "state": "open",
   "merged": false,
   "merged_at": null,
   "mergeable": false,
   "mergeable_state": "dirty"
   }

The following endpoint also returns HTTP 404, meaning GitHub does not recognize the PR as merged:
GET /repos/ladenexpert/inventory-management-system/pulls/88/merge

Additionally:

• The GitHub web interface continues to display "Checking for the ability to merge automatically..."
• The PR remains listed among open pull requests.
• Its issue timeline has no recorded merged event.
• The original remote PR branch still exists.
• Refreshing the page and rechecking the API on November 5 did not resolve the discrepancy.

This suggests that Git object integration and PR lifecycle metadata are inconsistent.

5. CI and security validation
   All six checks on the exact PR head da42bd74 completed successfully:
   CI:

• PHP 8.2 — SUCCESS
• PHP 8.3 — SUCCESS
• Production Build and Audit — SUCCESS

CI run:
https://github.com/ladenexpert/inventory-management-system/actions/runs/41815460499

Security:

• PHP and JavaScript SAST — SUCCESS
• Dependency Security Gate — SUCCESS
• Secrets Security Gate — SUCCESS

Security run:
https://github.com/ladenexpert/inventory-management-system/actions/runs/41815460309

No workflow run has been verified against the exact integration commit e844e9bc. This is being reported separately from the PR metadata inconsistency.

6. Expected versus actual behavior

Expected:
Once the pull request's head commit has been integrated into the target branch through the recorded merge commit, GitHub should recognize the completed integration and reflect the appropriate PR lifecycle state.
Actual:
The merge commit exists in the base branch history, but the PR remains OPEN, with merged=false and mergeable_state=dirty.

7. Questions for GitHub

• Could this be caused by a missed or delayed pull request lifecycle event during the November 4 service incident?
• Is there a known issue where the Git commit is successfully integrated but the PR metadata fails to transition to MERGED?
• Is there a supported reconciliation or repair mechanism that can associate the existing merge commit with PR #88?
• Can GitHub staff investigate the internal PR lifecycle state or advise how to escalate this case?
• If the PR metadata cannot be repaired, what is the safest administrative disposition that preserves the original commit history and avoids creating a duplicate merge?

8. Safety constraints and actions already taken

To preserve repository integrity:

• I have not force-pushed or rewritten history.
• I have not reset or modified the develop branch.
• I have not attempted a second merge.
• I have not closed PR #88 manually.
• I have retained the remote documentation branch while the inconsistency is being investigated.
• No database, deployment, or production branch operations were performed.

I am using GitHub Free and would appreciate guidance from the community or GitHub staff on the appropriate escalation path.

Thank you for your assistance.

[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. ⭐