Workflow runs created with 0 jobs on fork of large repository (huggingface/transformers) — jobs never planned, runs can't be cancelled

[Goalina]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Summary

After forking huggingface/transformers (a very large repo with hundreds of workflow files),
manually triggered workflow_dispatch runs are created successfully but always show 0 jobs.
The runs stay in queued status indefinitely and cannot be cancelled.

Affected repositories

• Goalina/transformers (fork of huggingface/transformers)
• codemayq/transformers (fork of huggingface/transformers)

Steps to reproduce

1. Fork huggingface/transformers 2. Create a simple custom workflow .github/workflows/test.yml:

name: test
on:
  workflow_dispatch:
jobs:    test:
    runs-on: ubuntu-latest      steps:
      - run: echo "hello"

3. Trigger via workflow_dispatch
4. Observe: run is created with status queued, but jobs count = 0
Expected behavior
Job records should appear under the workflow run immediately after triggering.

Actual behavior
- GET /repos/{owner}/{repo}/actions/runs/{run_id}/jobs returns total_count: 0
- Run stays queued indefinitely — no jobs are ever planned
- Run cannot be cancelled from the UI or API
- Changing runs-on to ubuntu-latest (GitHub-hosted runner) has the same result
- Settings → Actions → General is set to "Allow all actions and reusable workflows"

Affected run IDs
- https://github.com/Goalina/transformers/actions/runs/28376796444
- https://github.com/Goalina/transformers/actions/runs/28376220635
- https://github.com/codemayq/transformers/actions/runs/28370120572
- https://github.com/codemayq/transformers/actions/runs/28366636684

Hypothesis
huggingface/transformers has hundreds of workflow files. We suspect that when forking  such a large repository, GitHub's internal Actions workflow indexing/initialization for
the fork gets stuck or fails silently. This leaves the fork's Actions dispatch service  in an incomplete state where job planning never executes, even for simple custom workflows
that have nothing to do with the upstream's workflow files.

Environment

- GitHub.com (not GHES)
- Both affected repos are public forks
- Issue persists across multiple days and multiple workflow runs

[MuteeStack]

The symptoms you describe (queued, 0 jobs, and GET /jobs returning total_count: 0) usually indicate that the workflow never reaches the job planning stage, rather than a runner issue. Since the same behavior occurs with ubuntu-latest, it's unlikely to be related to ARC or self-hosted runners.

A few things I'd check:

1. Verify the workflow is actually the version on the default branch.
   workflow_dispatch only works for workflows that exist on the repository's default branch. If the workflow only exists on another branch, GitHub can create a run without ever planning jobs.

2. Confirm Actions are enabled for the fork.
   Besides Settings → Actions → General, verify there aren't any organization- or enterprise-level policies preventing workflow execution.

3. Rule out repository-specific state.
   Create a brand-new public repository (not a fork), add the exact same workflow, and trigger it. If it works there but not in multiple forks of the same repository, that strongly suggests the issue is specific to those forked repositories rather than the workflow itself.

4. Check whether all workflow runs in the fork are affected.
   If every manually triggered workflow—including a minimal one like your example—remains at 0 jobs, that points to a problem before workflow planning rather than with any individual workflow file.

If you've already verified all of the above, then this starts looking like a GitHub Actions backend issue affecting those repositories. The fact that:

• multiple independent forks exhibit the same behavior,
• GitHub-hosted runners (ubuntu-latest) are also affected,
• the Jobs API consistently returns total_count: 0, and
• runs cannot even be cancelled,

suggests the workflow planner is never producing a job graph.

At that point, I'd recommend opening a GitHub Support ticket and including the affected repository names, run IDs, and the observation that even a minimal workflow_dispatch workflow on the default branch never generates any jobs. The run IDs you've collected should help GitHub investigate whether the repositories' Actions state or workflow indexing is stuck internally.