GitHub Actions events routed to synthetic BuildFailed workflow with 0 jobs

[zhangnings-eng]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

We are seeing what appears to be a GitHub Actions workflow-registration / event-dispatch failure in a private repository.

Symptoms

New push and pull_request events are no longer dispatched to the repository's legitimate active workflow.

Instead, GitHub creates runs associated with a synthetic/deleted workflow record:

• workflow ID: 356217915
• workflow name: empty
• workflow path: BuildFailed
• conclusion: startup_failure
• jobs: 0
• no real job starts
• no check runs are created

Active workflow

The legitimate active workflow is:

• workflow ID: 333213605
• path: .github/workflows/finance-v1-phase0.yml

It previously ran successfully on the current canonical branch.

Last known successful run:

• run ID: 34613310625
• exact SHA: a6ed2684ef94e9c38aa350cd418ea8010efcb6c5
• conclusion: success
• 4 real jobs executed successfully

Affected runs

PR event:

• run ID: 34662717668
• exact SHA: 13c3e4f657cfdeeaedb5fd075d3813f816d68c81
• result: startup_failure
• jobs: 0

Another PR event:

• run ID: 34668355669
• exact SHA: 1533936fdf42f6933549b08e2203b2124a30dd2e
• result: startup_failure
• jobs: 0

Push event for the same SHA:

• run ID: 34668353616
• result: startup_failure
• jobs: 0

Exact-SHA recovery probe:

• run ID: 34668960208
• reproduced the same synthetic BuildFailed workflow
• jobs: 0

What we verified

• GitHub Actions is enabled.
• Allowed actions are set to all.
• The canonical workflow file still exists.
• The workflow file/blob is unchanged across the affected heads.
• Neither affected PR modifies the workflow.
• The legitimate workflow previously executed successfully.
• The failing check suites contain zero check runs.
• Attempting to rerun the synthetic failure returned:
  403 This workflow run cannot be retried
• A fresh exact-SHA no-content push reproduced the same BuildFailed routing.
• The temporary recovery ref was deleted afterward.
• No persistent repository mutation remains.
• No application or workflow workaround was applied.

This does not appear to be a YAML parsing or application-code issue because the same workflow content previously ran successfully and current events are being associated with a different synthetic workflow ID.

Expected behavior

push and pull_request events should dispatch to active workflow 333213605 and create its normal jobs.

Actual behavior

Events are routed to workflow 356217915 / BuildFailed, immediately ending as startup_failure with zero jobs.

Request

Is there a known GitHub Actions backend issue where an orphaned/deleted synthetic workflow registration intercepts repository events?

If this requires GitHub-side repair, could the repository's workflow registration / dispatcher mapping be reindexed or reset so events route to the active workflow again?

I found similar recent reports describing the same BuildFailed / startup_failure / zero-job behavior.

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

[zhangnings-eng]

Additional cross-domain evidence strengthens the repository-level routing diagnosis.

This is now confirmed to affect not only pull_request events but also a normal push event generated by a Shared recovery probe.

Normal push recovery probe

Branch:
codex/shared-ci-actions-recovery-01-pr283-1533936f

Exact SHA:
1533936fdf42f6933549b08e2203b2124a30dd2e

Run:
34668960208

Event:
push

Result:

• workflow ID: 356217915
• path: BuildFailed
• conclusion: startup_failure
• jobs: 0

So the problem is not limited to PR event handling.

Independent Store Client PR also affected

PR #284 has now advanced to exact head:

3157d5e490e6bac3f01aae91637e180e5191a993

Its latest PR run:

34669500344

also resolves to:

• workflow ID: 356217915
• path: BuildFailed
• conclusion: startup_failure
• jobs: 0

This means the same synthetic workflow is now affecting:

• a Sales PR
• a Platform/Security PR
• a Store Client PR
• a normal Shared recovery push

while the legitimate active workflow previously executed successfully on canonical.

This further reduces the likelihood of a Domain-specific PR/content issue and points to repository-level GitHub Actions workflow registration / event-dispatch state.