Actions rerun shows attempt 3 queued, then returns to startup-failed attempt 2 — new attempt never persists

[ch0c01dxyz]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Other

Discussion Details

Hi all,

I'm seeing a persistent GitHub Actions startup problem on one private repository and would appreciate any pointers on what causes it or how to get CI to complete at this exact commit.

Repo: ch0c01dxyz/UMNIA-APP (private — the run link below won't be viewable, but the details are the full picture)
Branch: f1-03-identity
Commit: 5151ac9dd05461126797be391b07c4c030e91ff9
Run: https://github.com/ch0c01dxyz/UMNIA-APP/actions/runs/43048988523 (workflow "CI", run #44)

What happened:

• Attempt 1 (push, Nov 11): business-api SUCCESS, web SUCCESS, owner-flow-e2e FAILED at "Install Playwright browsers" (Ubuntu mirror DNS failure; no Playwright tests ran).
• Attempt 2 (failed-job rerun, Nov 12 03:18 WIB): "Startup failure", zero jobs.
• Three full "Re-run all jobs" (Nov 12 ~04:48, Nov 12 ~15:29, Nov 13 ~03:57 WIB): the UI showed "Latest Feature request: support release details #3 Queued" (about 13, 25 and 5 minutes), then the page reverted to attempt 2 and /attempts/3 returns 404. Zero jobs ran in any of them. The latest request ID is B7AD:3C7985:73DB3:E26AF:6AF62843 (earlier IDs: BA88…, 3FC7…, 65EB…).
• The only annotation is the generic: "An unexpected error has occurred and we've been automatically notified. Errors are sometimes temporary, so please try again…"

What I've already checked:

• Repository Settings → Actions: Actions enabled, "Allow all actions and reusable workflows", no warning or banner about limits or disabled execution.
• GitHub Status: "All Systems Operational", Actions "Operational — Normal", no active incident.
• The same workflow and commit executed normally in attempt 1, so this doesn't look like a workflow validation error.
• A private Support ticket (#4994633) was closed without investigation, pointing to Community Discussions / Docs / Skills.

Question: what makes a rerun attempt display as Queued and then never persist as an attempt, and how can I complete CI at this exact commit without changing source merely to trigger another run? I've stopped blind retries.

Thanks in advance for any insight.

[Toroosnc]

GitHub is failing to queue the rerun because the specific run record or commit state is stuck in an internal database lock or corrupted dispatcher state.

To force a run without changing code:

1. Push an empty commit (git commit --allow-empty -m "trigger CI" and push) to generate a fresh workflow run ID.

2. Or, via GitHub CLI, trigger a workflow dispatch or create a new branch pointing to that commit to bypass the corrupted run history.

[kaluarachchiteshan]

Hi,

You've documented this carefully. A rerun that shows "Queued" and then disappears, with /attempts/3 returning 404, suggests the run-attempt record is being created and then rolled back on GitHub's side. That would match the generic "unexpected error" annotation, and it is not a workflow validation problem. Community members can't repair that state, but here are ways to get CI to complete at this exact commit.

1. Try a different kind of rerun

Attempt 2 (the failed-job rerun) ended in a startup failure with zero jobs, so later reruns may be inheriting a broken run state. Try these in order and check whether they behave differently:

# rerun only the failed job from the latest good attempt
gh run rerun 43048988523 --failed

# rerun a single job by ID (get IDs from attempt 1)
gh run view 43048988523 --attempt 1 --json jobs --jq '.jobs[] | {name, databaseId}'
gh run rerun 43048988523 --job <job-id>

# rerun with debug logging
gh run rerun 43048988523 --debug

If the API call (POST /repos/ch0c01dxyz/UMNIA-APP/actions/runs/43048988523/rerun) returns a different error than the UI, include that response in your support ticket.

2. Start a new run at the same commit without changing source

This avoids a new commit, and a fresh run does not depend on the broken run record:

• If the workflow has workflow_dispatch: in its on: block, run it manually on the branch f1-03-identity:

gh workflow run ci.yml --ref f1-03-identity

(Replace ci.yml with the actual file name.) This creates a new run for the branch head, which is commit 5151ac9.

• If it only triggers on push or pull_request, adding workflow_dispatch: needs a workflow change, so it can't be done without a commit. Another option is closing and reopening the pull request, which triggers pull_request workflows on the same head commit without changing code.

3. Check the possible causes of a rerun that doesn't persist

• Concurrency group: a concurrency: block (especially with cancel-in-progress) can drop or replace a queued attempt, so look at it.
• Required reusable workflows, rulesets or environment protection rules: check Settings → Rules and any required workflows. A rule that blocks the rerun can fail on the service side.
• Billing and spending limits (private repository): check Settings → Billing and licensing for exhausted minutes or a payment problem.
• Expired attempt data: attempt 1's job artifacts and logs retention doesn't normally block a rerun, but if the run is old enough that cached data is gone, rerun can fail. Starting a new run avoids this.

4. Escalate with the request IDs

Your support ticket was closed without investigation, so make the next request concrete. Reply on ticket #4994633 and ask for human review, or open a new one at https://support.github.com/contact with:

• run ID 43048988523 (run #44, workflow "CI")
• commit 5151ac9dd05461126797be391b07c4c030e91ff9 and branch f1-03-identity
• the timeline: attempt 1 pass/fail, attempt 2 startup failure, and the three full reruns with their times
• the request IDs (B7AD:3C7985:73DB3:E26AF:6AF62843 plus the earlier ones)
• that /attempts/3 returns 404 and the annotation is the generic "unexpected error" message

5. Separate problem: the original failure

Attempt 1's owner-flow-e2e job failed at "Install Playwright browsers" because of an Ubuntu mirror DNS failure. That is a transient network error. Once a run works, it may fail there again, so consider adding a retry step (for example a small retry loop around npx playwright install --with-deps) or caching the browsers.