PR events routed to deleted BuildFailed workflow; active CI does not start

[StoneFung]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

Hello GitHub Actions team and community,

I am seeing repeated GitHub Actions startup_failure runs for a pull request, but the runs are being associated with a deleted internal workflow record instead of the repository’s active CI workflow.

Repository and pull request

Repository:

https://github.com/StoneFung/ecommerce-creative-employee

Pull request:

https://github.com/StoneFung/ecommerce-creative-employee/pull/894

PR state:

• Open
• Draft
• Mergeable and CLEAN
• Head branch is in the same repository
• No merge conflict

Exact PR head SHA:

d6408c525c1ef8a9d078f522eb4f6fd3107c1ecb

Base SHA:

ec17250bd0289b0e3375afa9aef3aae06e511e2b

Expected workflow

The repository has one active workflow:

• Workflow ID: 300177057
• Name: CI
• Path: .github/workflows/ci.yml
• State: active
• Trigger: pull_request targeting main

The workflow file is unchanged between the PR base and head.

Base workflow blob SHA:

103e22b75a113371b76e002a42aba697862086f7

Head workflow blob SHA:

103e22b75a113371b76e002a42aba697862086f7

The PR does not modify .github/workflows/ci.yml.

Actual behavior

Every new pull_request event for this PR/head creates a run associated with:

• Workflow ID: 325896319
• Name: empty
• Path: BuildFailed
• Workflow state: deleted
• Conclusion: startup_failure
• Jobs: 0
• Check runs: 0
• Logs: unavailable

The active CI workflow does not create a run for the exact PR head, and gh pr checks 894 reports that no checks are present.

Recent affected runs:

• https://github.com/StoneFung/ecommerce-creative-employee/actions/runs/30786107184
• https://github.com/StoneFung/ecommerce-creative-employee/actions/runs/30786108933
• https://github.com/StoneFung/ecommerce-creative-employee/actions/runs/30785401333
• https://github.com/StoneFung/ecommerce-creative-employee/actions/runs/30785404418
• https://github.com/StoneFung/ecommerce-creative-employee/actions/runs/30783538934
• https://github.com/StoneFung/ecommerce-creative-employee/actions/runs/30783419967

All of these runs target the same exact head SHA shown above.

Repository Actions settings

I verified:

• GitHub Actions is enabled.
• Allowed actions: all
• The intended CI workflow is active.
• The pull request is clean and mergeable.
• There are no branch/path filters excluding this PR.
• The workflow file content is identical at base and head.
• No jobs or check runs are created, so there are no execution logs to inspect.

Recovery already attempted

I performed one controlled repository-side recovery attempt:

1. Disabled workflow 300177057.
2. Verified its state became disabled_manually.
3. Immediately enabled it again.
4. Verified its state returned to active.
5. Closed and reopened PR #894 once without changing its head, base, Draft state, or repository content.

After this refresh, GitHub created new runs 30786107184 and 30786108933, but they were again associated with deleted workflow 325896319 / BuildFailed, with zero jobs and zero check runs.

I have not modified the workflow, created another commit, deleted any runs, or repeatedly retriggered the PR.

Expected outcome

New pull_request events for PR #894 should start the active workflow:

• CI
• .github/workflows/ci.yml
• workflow ID 300177057

Instead, the events continue to target the deleted BuildFailed workflow record.

This appears to be an internal workflow-registration, event-routing, or Actions scheduling-state problem rather than a workflow YAML or pull request content problem.

Could GitHub staff investigate why this PR/head is still associated with deleted workflow ID 325896319 and restore routing to the active CI workflow?

If this requires GitHub Support rather than a repository-side fix, please escalate it or advise how I can reach the appropriate Actions support team. No repository content change is requested.

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

[danyasync]

this looks like repo-side ghost state, not a normal on: pull_request filtering issue.

if a fresh PR event creates a run whose workflow_id points to a record with:

path: BuildFailed
state: deleted

while the active CI workflow never receives the event, then the Actions registry and the event dispatcher disagree about which workflow registration should handle it. changing the YAML, deleting old runs, or toggling Actions on and off is unlikely to repair that record.

this also looks very close to this earlier report. it has the same deleted BuildFailed entry, the same startup_failure runs, and the same problem with the legitimate CI workflow not starting.

the documented REST API lets you list, inspect, enable, disable, and dispatch workflows, but it does not expose an endpoint for deleting a workflow registration. once the broken entry already reports state: deleted, there is no real repo-side cleanup left to do.

i would capture one fresh PR event and attach these outputs:

gh api repos/OWNER/REPO/actions/workflows --paginate \
  --jq '.workflows[] | [.id, .name, .path, .state] | @tsv'

gh api 'repos/OWNER/REPO/actions/runs?event=pull_request&per_page=100' --paginate \
  --jq '.workflow_runs[] | [.id, .workflow_id, .status, .conclusion, .head_sha, .created_at] | @tsv'

the important bit is correlating:

• the fresh failing run ID
• its workflow_id
• the deleted BuildFailed entry
• the active CI workflow ID
• the PR head SHA
• the event timestamp

if the active workflow supports workflow_dispatch, one more useful control would be:

gh workflow run ci.yml --ref main

replace ci.yml with the actual workflow file.

if the manual run starts under the active workflow ID, but the next PR event still lands on the deleted BuildFailed ID, that pretty much rules out the workflow file and runner setup. the routing state itself is broken.

at that point, i would open a GitHub Support ticket with the IDs and timestamps and ask them to purge or repair the orphaned workflow registration server-side. i do not see a clean workaround that can remove it from the repository side.

pretty nasty bit of ghost state :)

[StoneFung]

Thank you. This matches the evidence I collected.

I already captured fresh pull_request events after a controlled workflow registry refresh.

The workflow identities are:

300177057    CI    .github/workflows/ci.yml    active
325896319          BuildFailed                  deleted

Workflow 325896319 was queried directly after the current workflow list showed only the active CI workflow.

The two newest runs were generated immediately after:

1. disabling active workflow 300177057,
2. confirming disabled_manually,
3. enabling it again,
4. confirming it returned to active, and
5. closing and reopening Draft PR #894 once without changing its head or base.

The resulting fresh runs are:

30786107184    325896319    completed    startup_failure    d6408c525c1ef8a9d078f522eb4f6fd3107c1ecb
30786108933    325896319    completed    startup_failure    d6408c525c1ef8a9d078f522eb4f6fd3107c1ecb

Both runs have:

jobs: 0
check runs: 0
workflow path: BuildFailed
workflow state: deleted
event: pull_request

The expected active CI workflow created no run for that exact head.

Earlier runs on the same head show the same association:

30785401333    325896319    startup_failure
30785404418    325896319    startup_failure
30783538934    325896319    startup_failure
30783419967    325896319    startup_failure

The active workflow file does not define workflow_dispatch, so gh workflow run ci.yml --ref main is not applicable. I do not want to modify the workflow solely to add a diagnostic trigger, because the base and PR-head workflow blobs are already identical:

103e22b75a113371b76e002a42aba697862086f7

The PR remains Open, Draft, clean and mergeable:

https://github.com/StoneFung/ecommerce-creative-employee/pull/894

No additional repository-side retries or content changes will be made.

Could a GitHub staff member escalate this for server-side workflow registry/event-routing cleanup, or advise how to reach the Actions team able to inspect workflow ID 325896319?

[StoneFung]

This issue remains reproducible and continues to block all exact-head CI checks for PR #894. Could a GitHub Actions staff member please review or escalate the deleted-workflow routing evidence above?