Workflow completed/failure but job remains queued; Internal server error and rerun-failed-jobs returns 403

[benfurkanbaris]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Actions Runner

Discussion Details

A GitHub.com Actions workflow is in an inconsistent state. Some jobs completed successfully, but another job never recorded a Set up job step. The workflow API reports completed/failure while the affected job remains queued, with a null conclusion and no steps. Its actual job-page annotation says Internal server error. A correlation ID is retained privately.

One explicitly authorized request to rerun only failed jobs returned HTTP 403: This workflow run cannot be retried. The attempt number did not increase and no new job started. The workflow is enabled, the run is recent, and this was its first attempt. The same source tree previously passed its checks.

The account's support portal says Technical support not included. I am not sharing a private repository URL, run/job IDs, commit hashes, workflow source, logs, screenshots, credentials, or correlation ID publicly.

Is there a supported route to have GitHub staff inspect and reconcile the run/check state so that only the unstarted job and its skipped dependent job can be completed? What minimal information should be supplied through a private channel? I do not want to rerun already successful jobs, change permissions or runner configuration, or create new commits just to trigger another run.

[sohom-since-006]

1. Is there a supported route for GitHub staff inspection?

Yes. Since standard user-facing actions and APIs are locked out by the corrupted record, the only path is to report the backend inconsistency to GitHub Support.

2. What minimal information should be supplied?

To avoid exposing sensitive details, you can safely open a private ticket and supply only this metadata:

• Repository name/path (or indicate it is private)
• Workflow file path within the repo
• Run ID and Job ID of the affected run
• The private Correlation ID you retained from the internal server error response
• Timestamp of when the failure occurred

3. Will this require changes on your end?

No. You do not need to push new commits, modify runner configs, or alter permissions. Once GitHub Support references the correlation ID on their internal tracing logs, engineers can manually clear, reconcile, or reset the orphaned run state on the backend.

[benfurkanbaris]

Thanks for the guidance. The account support portal says "Technical support not included." Its repository-features form offers Templates, Releases, Insights, and Branches, with no matching Actions category. Is there a supported private intake route for this workflow/run-state inconsistency without upgrading or changing the account plan? I will keep the repository, run/job IDs, and correlation ID out of this public thread.

[christoferpedrosanchezzuzunaga-eng]

Hello @benfurkanbaris,

The HTTP 403 error on rerun-failed-jobs happens because the GitHub API expects all jobs in a completed run to have reached a terminal conclusion (failure, success, or cancelled). Because one job is stranded in "queued" with no step data, the workflow run is in an invalid state that the retry endpoint rejects.

Since the retry API won't accept the malformed run ID, the only way forward is:

1. Don't retry the existing run; trigger a brand new workflow run (either via gh workflow run or pushing a minor commit).
2. If the stuck job keeps the concurrency lock held, push a commit that temporarily alters the concurrency: group name in the workflow YAML to bypass the lock on subsequent runs.