Github actions

[xxlyusufi61-bot]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Title:

GitHub Actions workflows repeatedly fail with "startup_failure" before creating any jobs

Description:

Hello GitHub Community,

I am experiencing a persistent issue with GitHub Actions in my repository.

Repository:
https://github.com/xxlyusufi61-bot/general-super-loto

Workflow:
"GENERAL NVIDIA Manual Unlock"

Workflow file:
".github/workflows/general-nvidia-unlock.yml"

Workflow ID: "396451994"

Three consecutive manual workflow runs failed with the conclusion "startup_failure":

• Run Feature Request: Push Notifications and Badges for Requested Reviews #11: https://github.com/xxlyusufi61-bot/general-super-loto/actions/runs/43095727802
• Run Feature Request: Blockquote Button #12: https://github.com/xxlyusufi61-bot/general-super-loto/actions/runs/43096694288
• Run Feature Request: Dual account support/troubles #13: https://github.com/xxlyusufi61-bot/general-super-loto/actions/runs/43097556543

What we have investigated:

1. All three runs were created successfully but ended with "startup_failure".
2. The GitHub Actions API returned an empty jobs array for all three runs.
3. No runner job was created, so checkout, setup-python, and the workflow script never started.
4. The workflow YAML file has not changed since a previous successful run.
5. The "general_nvidia_guard.py" file also remained unchanged.
6. An earlier run of the same workflow, run More defined voting system #10, completed successfully:

https://github.com/xxlyusufi61-bot/general-super-loto/actions/runs/42706832733

7. Other workflows in the same repository continued to run successfully during the same period.

Workflow configuration:

The workflow uses:

• "workflow_dispatch"
• "ubuntu-latest"
• Python 3.12
• "actions/checkout@v4"
• "actions/setup-python@v5"
• A concurrency group shared with another workflow:
  "general-nvidia-api"
• "cancel-in-progress: false"

What we need help with:

Could someone help determine why GitHub Actions creates the workflow run but fails before creating its first job?

Specifically:

1. Can GitHub investigate the internal check-suite and job initialization records for these three run IDs?
2. Is this potentially a GitHub-hosted runner provisioning or workflow orchestration issue?
3. Could there be an out-of-sync workflow run or check-suite state?
4. Is there a recommended way to recover the workflow without changing its logic or weakening its concurrency protection?

We do not want to make random workflow changes because the same workflow previously worked successfully.

We would appreciate help identifying the actual root cause and a safe resolution.

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

[kaluarachchiteshan]

Hi,

startup_failure with an empty jobs array means GitHub rejected the run before any job was created. It is not a runner provisioning problem, and it is not caused by your Python script. Here is how to narrow it down without changing the workflow logic.

1. Open the run page and look for the error banner

Open one of the failed runs (for example run #13) in the browser. Startup failures usually show an annotation or error message at the top of the run summary, such as:

• an invalid workflow or expression error
• an action that is not allowed by the repository or organization policy
• a reusable workflow that cannot be accessed
• a billing or spending limit problem

The API returns an empty jobs array, but the UI often shows the reason.

2. Check which ref the manual run used

For workflow_dispatch, GitHub uses the workflow file from the branch or tag you selected when running it. Confirm that this ref contains the same .github/workflows/general-nvidia-unlock.yml as the successful run #10. A different branch can have a different file even if the default branch is unchanged.

3. Check the Actions policy

Go to Settings → Actions → General and check "Allow actions and reusable workflows". If the policy is "Allow select actions", make sure actions/checkout@v4 and actions/setup-python@v5 are allowed. If the setting was changed by an organization admin after run #10, this alone can cause a startup failure.

4. Check billing, limits and permissions

• For private repositories, check that included minutes or the spending limit aren't exhausted (Settings → Billing).
• If the workflow has a permissions: block, make sure it is valid.
• Check that the concurrency group name general-nvidia-api has no invalid expression in it.

5. Check for a GitHub incident

Check https://www.githubstatus.com for Actions incidents around the time of the failed runs. Similar "stuck" or "never started" reports from other users have run IDs very close to yours (4309xxxxxxx), which suggests a platform-side issue during that period rather than a problem in your repository.

6. Recover without changing the workflow

Once the cause above is cleared (or the incident has ended), run it again:

gh workflow run general-nvidia-unlock.yml --ref <branch>

Or use "Run workflow" in the Actions tab. You don't need to edit the YAML or weaken the concurrency protection. Note that "Re-run" on a startup_failure run generally cannot work, so start a new dispatch instead.

7. If it still fails, contact GitHub Support

Discussions are community-run, and GitHub staff cannot inspect internal check-suite records here. Open a ticket at https://support.github.com/contact and include:

• the repository and workflow ID (396451994)
• the three run IDs (43095727802, 43096694288, 43097556543)
• the successful run (42706832733) for comparison
• the times of the failures and that jobs is empty

Also note that the topic area "ARC (Actions Runner Controller)" is for self-hosted Kubernetes runners. Since you use ubuntu-latest, the "Actions Runner" or "Actions" area is probably a better fit.