GitHub Actions startup_failure with synthetic BuildFailed workflow and zero jobs on private repository

[gokrevia]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

All GitHub Actions events in one private repository are currently failing before job creation.
The failing runs reference workflow ID 355263892, whose API metadata is:

• name: empty
• path: BuildFailed
• state: deleted
• conclusion: startup_failure
• jobs: 0
• check runs: 0
  First occurrence: 2026-09-10T20:50:37Z.
  The repository has 15 valid active workflows under .github/workflows/*.yml. All three self-hosted runners are online and idle, and no job is ever offered to them.
  The strongest control is that commit 6b25af5f7a successfully created and ran normal workflows at 19:33 UTC, while the exact same commit later produced the synthetic BuildFailed failure on another branch. This strongly rules out repository tree contents as the direct variable.
  We also validated all historical workflow YAML available locally and found no malformed or empty workflow. Actions are enabled and allowed actions are unrestricted.
  One local operation cannot be fully excluded as a trigger: at 19:46 UTC, after the last successful workflow execution, two merged branches were deleted using the GitHub REST Git Refs API. Equivalent ref deletions had occurred earlier without breaking Actions, so we do not know whether this is related.
  We are not claiming a confirmed GitHub backend defect, but current evidence points with high confidence to a workflow registration/build or repository/account backend-state issue.
  Could GitHub staff please inspect:

1. Why workflow registration/build failed at 2026-09-10T20:50:37Z.
2. Whether workflow ID 355263892 is an internally generated BuildFailed placeholder.
3. Why an earlier Rust static job was never dispatched despite an idle matching self-hosted runner.
4. Whether DELETE operations against Git refs can affect Actions workflow registration/dispatch state.
5. Whether the Actions workflow registration state for this repository can be purged/reindexed/rebuilt.
   Representative failing run IDs:
   34528763019, 34528811153, 34529121103, 34529121817, 34529210087, 34529268806, 34529295969.
   GitHub Status currently reports Actions operational.

[gokrevia]

Update: controlled workflow_dispatch reproduces startup_failure with the real workflow identity but still creates zero jobs
I ran exactly one additional diagnostic after preserving the incident evidence.
I directly dispatched a known-valid, dispatch-only workflow on the default branch:
.github/workflows/self-hosted-runner-smoke.yml
Preflight:

• workflow ID: 312763155
• workflow state: active
• ref: main
• HEAD: aa1fb2a0224832e1d56b5102254ed998c78103be
• all three matching self-hosted runners: online and idle
  The dispatch API returned HTTP 204 normally.
  Resulting run:
• run ID: 34541022401
• workflow ID: 312763155 (the real workflow ID)
• workflow name: Self-hosted runner smoke — x86
• path: .github/workflows/self-hosted-runner-smoke.yml
• event: workflow_dispatch
• branch: main
• status: completed
• conclusion: startup_failure
• jobs: 0
• check suite: 93573686500
• check runs: 0
• runner assigned: none
• created: 2026-09-10T23:11:34Z
• updated: 2026-09-10T23:11:35Z
• logs: none (/logs returns 404)
  Importantly, this run did not use the synthetic BuildFailed workflow. GitHub successfully resolved the actual registered workflow, its name and path, but still failed before constructing any jobs.
  This changes our interpretation:
• workflow discovery/registration appears to be working;
• the synthetic BuildFailed object seen on push/PR events appears to be an attribution placeholder/consequence when the earlier workflow-build stage fails;
• the current failure appears to occur after workflow discovery but before a job graph is created;
• because jobs=0, none of the self-hosted runners ever receives work.
  No AWS calls, deploys or repository changes were involved in this test. The workflow's optional AWS validation input remained disabled.
  We performed exactly one dispatch and have stopped further probing.
  Could GitHub staff please specifically investigate why job-graph construction / pre-job evaluation is failing for run 34541022401, despite it targeting an active, known-valid workflow directly on main?
  The key internal objects are:
• run: 34541022401
• workflow: 312763155
• check suite: 93573686500
  This is now a more precise question than our original request to reindex workflow registration, because this test shows the workflow registration itself can be resolved correctly.