GitHub Pages rerun stuck queued; force-cancel returns 409

[Aur-iii]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

Repository: https://github.com/Aur-iii/aurifellmusic
Stuck run: https://github.com/Aur-iii/aurifellmusic/actions/runs/41288355789
Check suite ID: 111906192541

My Pages source is “Deploy from a branch” (main), not a custom Actions workflow.

The first attempt of run #177 failed in actions/deploy-pages@v5 with HTTP 400. GitHub said deployment of commit 4d5474299839b0034120cceeef1d900c58d5fe84 was blocked by an in-progress deployment for a3058cc663dbbba5e1aa02074e9dade5cf9168f6. Error request ID: 0430:371B8E:3E276FE:CE308EA:6AE6F624.

However, the earlier workflow run #176 completed successfully, and the GitHub Pages deployment status API for a3058cc663dbbba5e1aa02074e9dade5cf9168f6 returns “succeed”.

I reran #177, but the rerun has remained “Queued”. Cancelling in the UI says “Cannot cancel a workflow run that is not in progress.” The force-cancel API returns HTTP 409: “Cannot cancel a workflow re-run that has not yet queued.” Force-cancel request ID: F692:207AD5:1A5AD8B:5713B41:6AE76A5E.

The UI and API appear to disagree about run #177’s state. I’m asking for help clearing or resolving that stuck rerun/check suite only. Please preserve my earlier successful deployments and the currently live site; I’m not requesting that any other deployment be removed or cancelled. If fixing this requires changing one of them, please let me know first.

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

[devpryan7792]

This deadlock happens because GitHub Pages uses an internal deployment concurrency lock on the github-pages environment.

When your initial run failed with HTTP 400 (blocked by an in-progress deployment), the environment lock was left in a pending/orphaned state. The rerun is now stuck in "Queued" waiting for that lock to release. Because the job has not been picked up by a runner, the UI says it is not in progress, and the Actions cancel API throws HTTP 409 because it cannot cancel a rerun that hasn't fully queued into the runner pool.

Here are 3 ways to clear the deadlock without losing your site or previous deployments:

Method 1: Push an Empty Commit (Fastest & Safest)

GitHub's environment concurrency handler automatically cancels pending/queued runs for older commits when a newer commit arrives:

git commit --allow-empty -m "bust pages deployment lock"
git push origin main

This triggers a fresh workflow run that supersedes the stuck rerun and clears the queue lock.

Method 2: Toggle the Pages Build Source

Toggling the Pages source resets the internal deployment queue without deleting your repository or existing live assets:

1. Go to your repo Settings → Pages.
2. Under Build and deployment > Source, temporarily switch it from Deploy from a branch to GitHub Actions (or select a different branch and hit Save).
3. Wait 30 seconds, then switch it back to Deploy from a branch (main / / (root)) and hit Save.
   This forcibly purges the stale deployment lock on the github-pages environment.

Method 3: Clear the Stale Lock via Deployments API

Instead of trying to cancel the Actions run, target the underlying deployment lock directly using the GitHub CLI:

1. List active deployments for the environment:

   gh api repos/Aur-iii/aurifellmusic/deployments?environment=github-pages --jq '.[] | {id: .id, sha: .sha, created_at: .created_at}'

2. Mark the stuck deployment as inactive/failed to release the lock:

   gh api repos/Aur-iii/aurifellmusic/deployments/<STUCK_DEPLOYMENT_ID>/statuses -f state="failure"

Once the deployment status is updated, the environment lock clears immediately.