Replies: 9 comments
|
Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided. This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers. |
0 replies
|
Also having this issue. |
0 replies
|
I'm having this issue as well on a private repo. |
0 replies
|
Same here |
0 replies
|
same here. private repo |
0 replies
|
same problem with private repo |
0 replies
|
Same here. Got my ticket closed by Virtual Assistant |
0 replies
|
Same issue |
0 replies
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Type
Bug report — GitHub Actions workflow execution / scheduling
Summary
Two manually dispatched runs in our public repository remain
queuedwith zero jobs. The first run cannot be cancelled: normal cancellation reports that it is completed, while force cancellation reports that it has not been queued yet. A fresh dispatch of the same commit is also queued with zero jobs.Repository and affected runs
.github/workflows/build.yml— Build and Publishmain15735db9653c255a0a10ce23712866d1c05b5c09116393089894Observed API responses
Run queries return
status: queued,conclusion: null; jobs endpoints returntotal_count: 0. The first run's check suite is also queued with zero check runs.Normal cancellation of run 1:
Force cancellation of run 1:
After those cancellation failures, querying run 1 still returned
queued. Dispatching the workflow once more created run 2, which also has not produced any jobs.Checks performed
enabled: true,allowed_actions: all.active.concurrencygroup or deployment environment.ubuntu-latestand a Spark build job on${{ vars.SPARK_BUILD_RUNNER || 'ubuntu-24.04-arm' }}.SPARK_BUILD_RUNNERvariable was found. Organization-level policy/variable queries returned 403 with the available credentials, so organization restrictions have not been ruled out.Expected behavior and request
The runs should create jobs and execute, or reach a terminal status with an actionable error. Cancellation should consistently reflect the run's actual state.
Could GitHub staff investigate the scheduling/check-suite state for these run IDs, help clear any stuck records, and confirm whether an organization restriction or a backend issue is preventing job creation? This is blocking our container-image build and publishing workflow.
The documented symptoms under Troubleshooting workflows — Canceling Workflows appear similar, but we have not established the root cause.
All reactions