Synthetic BuildFailed workflow intercepts Actions runs with startup_failure and zero jobs

[DirJuanDanielRamirez]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

Hello GitHub Actions team,

I am experiencing a persistent Actions dispatcher/workflow-registration issue on a private repository.

A previously healthy canonical workflow no longer starts normally.

Current behavior:

• New workflow runs end immediately with startup_failure
• Zero jobs are created
• No named check contexts materialize
• The affected runs resolve to a synthetic workflow object
• The synthetic workflow has an empty name
• Its observed path is BuildFailed
• The legitimate workflow remains present and its YAML was previously executing successfully

This occurs before any job is created, so there are no job logs available.

Controlled self-service recovery has already been exhausted:

1. Neutral workflow re-registration/touch
2. Triggering from a stable branch
3. Deleting and recreating the workflow from the known-good canonical version
4. Restoring the candidate workflow byte-equivalent to the known-good version

The same BuildFailed / startup_failure / jobs=0 behavior persists.

This appears similar to other recent Community reports involving a stale/deleted/synthetic BuildFailed workflow registration intercepting legitimate workflows.

Could GitHub staff please advise whether this can be caused by stale/orphaned backend workflow registration or repository/account-side Actions dispatcher state?

Specifically, is there a staff-side purge/reindex or workflow registry repair that can restore dispatch to the legitimate .github/workflows/ci.yml workflow?

The affected repository is private. I have the exact repository name, canonical workflow ID, synthetic workflow ID, failed run IDs, commit SHAs, and complete reproduction evidence available if GitHub staff needs them through an appropriate non-public channel.

Thank you.

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

[MedChronicles]

The BuildFailed synthetic workflow with an empty name is what GitHub generates when the dispatcher can't resolve your push/trigger event to any valid workflow file at the ref being built — usually because the workflow file that existed on the branch/SHA the run is checking out is invalid, missing, or unparsable at that specific commit, even if your current default branch version is fine.
A few things that produce exactly this signature:
The workflow YAML was renamed/moved/deleted on the branch the event actually points to (not the branch you're looking at in the UI)
A tag or SHA-based trigger is resolving to an older commit where ci.yml didn't exist yet or lived at a different path
The workflow file has a YAML syntax error introduced in a commit that's still reachable by the trigger (e.g., merge commit, squash commit, or a stale ref) even though HEAD looks clean
Branch protection / required status checks still reference the old check name, so GitHub creates a placeholder BuildFailed context to satisfy the required check, since it can't find a job to attach it to
Byte-for-byte restoring the file on your default branch doesn't fix this because the dispatcher isn't reading your default branch — it's reading whatever ref/SHA triggered the event.
How to actually confirm and fix it
Go to the failed run → click the small commit SHA link at the top (not the branch name) → check .github/workflows/ at that exact SHA. Nine times out of ten the file is missing, empty, or malformed there.
Check Settings → Branches → your protection rule → Required status checks. If BuildFailed or an old check name is listed there, remove/re-map it. This alone causes exactly the symptom you're describing (empty name, zero jobs, synthetic object).
If using tag-triggered or workflow_call/reusable workflow patterns, confirm the caller isn't pinned to an old tag/SHA that predates the workflow file.
As a hard reset: delete the stale required-check entry in branch protection, push one new commit containing the known-good YAML, and let a fresh run create a brand-new check context from scratch rather than trying to reuse the old one.