Github actions: Stuck in "Expected — Waiting for status to be reported"

[AlexMachin1997]

Hi everyone,

So I’ve just raised a Pull Request for a personal project, I left it about a day and came back but in my Pull Request it still shows for my unit test related unit test’s. For my unit test workflow actions it’s stuck showing “Expected — Waiting for status to be reported” as seen in the screenshot below.

image1920×1080 252 KB

Based on what I can see there are certain test’s aren’t running, no logs or no errors it just hasn’t run the remaining unit test’s.

I’m not entirely sure what’s going wrong, it would be great if someone could assist me with my issue.

Thank’s,

Alex

[airtower-luna]

Have those workflows been triggered for that PR? If a check is required but that check doesn’t get triggered (e.g. because of a path filter, or because it has been renamed) the “expected check” will block forever.

[16oeahr]

For a workflow with path filter, how to make the workflow as required if it is triggered? i.e. Once it is triggered, how to block PR merge if it fails?

[darvid7]

+1 same question!

[p-flock]

https://github.com/orgs/community/discussions/26698#discussioncomment-6816209

having the same issue

[danielo515]

That is definitely a bug. Why would you want a status check that will never run to be required? Is there a way to ensure only make it required when the rules of that check will make it run?

[marcellodesales]

Also, even adding branch rules to the branch from the PR we can't dismiss or bypass the branch settings... First bug in Github in many years... I've tried everything and I need a github organization workflow to be run in all PRs... I can't see where the runner is being executed, since I own the Github Org and I own the Gitub action Runner instances in the org... Here's what I tried

• Defined myself as users who can dismiss PRs
• Defined myself as an Admin/Owner of the repository
• Re-created the PR with another branch

On top of that, there's no links to the actual action run so that we can verify what's been waiting for...!

[AlexMachin1997]

Yeah the action’s are triggered whenever a Pull Request is created.

There is no special filters within the job from what I can see in the workflow files, the only filters is the on: [pull_request]

Just in case I’ve done something unintentional here’s the link to the workflow action.

What’s a little strange is that when I go to the “Action’s” tab I can see all the workflow actions did in fact run (see screenshot attached below) however in the Pull Request I raised the status is still stuck in that “Expected - Waiting for status to be reported” state.

Screenshot of the “Actions” tab. FYI The Pull Request is called Styled-Components to Tailwind CSS

image1920×1080 275 KB

[airtower-luna]

I don’t see any workflow runs by those exact names in the Actions tab of that repository, it and it looks like the “Application testing / Running React-Testing-Library and Jest tests” job has been changed to use Node 16 only now, instead of 12.x and 14.x.

I suspect you might need to update the list of required checks (jobs) in the repository configuration, at least if those changes to the jobs were intentional.

[juampynr]

That was my case! I did change the job names. Thanks for the suggesion.

[AlexMachin1997]

Hmm that is strange.

The last time I updated my project I swapped out the “matrix” functionality which can on version 12 and 14 though since then it’s been set to run on only v16 as seen in the screenshot

image1920×1080 356 KB

.

I’ve also updated the workflow action versions numbers as you suggested though the workflow actions are still behaving the same as before sadly.

[AlexMachin1997]

Hmm seem’s like it’s wait for actions which simply don’t exist and haven’t for a while.

I can’t seem to find them in the “Actions” tab but it’s not appearing.

[airtower-luna]

AlexMachin1997:

Hmm seem’s like it’s wait for actions which simply don’t exist and haven’t for a while.

That’s exactly my point. Those jobs still seem to be configured as required in your branch protection rules, that’s what the “Required” label means. When you rename or remove jobs, you need to update any branch protection rules that use them.

[AlexMachin1997]

I’m confused now.

The changes where I specify the “NodeJS” version were merged months ago.

I’ve just created a new Pull Request with the updated github actions and I’m experiencing the same issue with the " Styled-Components to Tailwind CSS" 😕

[airtower-luna]

I’m talking about branch protection rules. I can’t see exactly which rules exist in your repository (that’s part of the repository settings, so not available to me as a random other user), but I can see those checks are shown as “required” in the PR. That means there is a branch protection rule that says those jobs must have passed before the PR can be merged.

Configuration of branch protection rules is completely separate from your workflows. I assume that at some point in the past you’ve marked the previous jobs as required checks (step seven in the documentation, or search for “required status checks”). Once enabled, those jobs are required by name.

You’ve changed job names, so you need to update the branch protection rule: Remove the old jobs, so waiting for jobs that don’t exist any more doesn’t block merging. And ideally add your new job (the non-matrix one) to that gets checked.

[c5k4]

Not really answer the 'Expected' question. Prisma Cloud / Code Aanlysis check normally runs within 15-20 minutes for the repo. Occasionally will get stuck in the Expected state. What might be going on and more importantly, how to get out of it to Merge the PR, without having to override it, using the merge without waiting check box.

[AlexMachin1997]

Ah gotcha.

So even though I updated the workflow actions I needed to modify the actual branch rules which were still present.

Annoying but less learned.

Thank’s for sticking with me @airtower-luna

[divyachowd]

[divyachowd]

[koo5]

In my case, there was a : somehow accidentally tacked onto the required job name. Not easy to figure out!

[p-flock]

following on from this question:
I have a required test akin to check_file_tests_if_file_changed which then runs a workflow file with multiple test jobs,

name: Run all tests for file

jobs:
  test1:

  test2:

  test3

when I set a branch protection rule to prevent merging until check_file_tests_if_file_changed has run, the check hangs and never gets a status reported even if the 3 child jobs pass.

But if I require the 3 child jobs individually, they will prevent merging to the protected branch even if they were skipped because there were no file changes

[koppor]

In my case, I had "path filters" on the PR. I wanted the deployment only happen if only tests were changed (src/main/test/** was ignored when triggering). However, we marked working deployment as a must. Thus, even if not triggered in some cases, it was required.

Removing any filter in the trigger solved the issue here.

For reference: Required changes at JabRef/jabref#10319; other information linked there.

[Diapolo10]

I've run into a similar issue. A community contributor put forth a pull request (Diapolo10/iplib3#105) to a project I'm maintaining, but the unit tests and linter do not run in the actual pull request.

They work fine for the individual commits, but I'd rather not force the pull request to go through manually.

[koppor]

I checked. The trigger pull_request was missing. Without that trigger, there is no check, even if the contributor "pushed". The difference is that "push" is in the repository itself - and (AFAIK) ignores activity of contributors in a pull request.

I submitted a PR fixing it at Diapolo10/iplib3#107.

[tomsit-ionos]

not sure if i understood here correctly, but an on.pull_request is not needed per see. The only thing needed AFAIKS is that the required check-job is executed somehow as part of a push the the head of the PR, i.e. for me an on.push is sufficient

[dyedwiper]

In my case there were merge conflicts and it turned out that "Workflows will not run on pull_request activity if the pull request has a merge conflict. The merge conflict must be resolved first.", like stated here: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request

[thisisthemurph]

In my case, this seemed to be a transient issue where the workflow didn't run (couldn't see it in the list of checks) but the result was still being awaited. I ran the following commands to force another push to the PR:

git commit --amend --no-edit
git push --force-with-lease

[raulelba]

I'm seeing this issue quite often. In my case it seems to be a happening when we amend a commit and force push to the branch while there are previous jobs still running. The action runs are cancelled, but sometimes they stay lingering their "waiting for status to be reported" and we cannot do anything to re-trigger them. I have tried everything that crossed my mind, from re-running the actions to force-pushing, but the status of the check won't change. When this happens in a check that's required it prevents the PRs from being merged.

[BlaineEXE]

I am encountering this issue here also rook/rook#14299, but in this case, there was no force-push that preceded it. It seems to have gotten stuck all on its own. I tried a force-push to get the test to rerun, to no avail.

It would be really nice to at least be able to re-run this check when it gets into stuck state like this. As it is, it seems like it's handled via some special mechanism that doesn't show up in github actions, and that's why it's blocking PRs randomly.

[BlaineEXE]

We have started to see this behavior regularly over the past week (more than 5 times) in github.com/rook/rook. Is GitHub aware of any ongoing issues with the DCO check?

[Galkon]

Feels like we are running into this every other PR / push we make -- incredibly frustrating. Is GitHub going to fix this?

[stevenh]

Seeing this on PR's which have worked flawlessly, seems to be no rhyme or reason. Example testcontainers/testcontainers-go#2664

[jarvis8x7b]

is there currently a fix for this? we're getting it on every PR now, ideally want to have it work properly rather than having to bypass branch protection rules

[stevenh]

When we see this, its all actions but not all PR's, very rarely triggers.

Given this I would recommend checking that your branch protection rules don't require an old or renamed action @AlexMachin1997 as this is what you'll see in that case.

[WowSuchRicky]

For anyone who arrives to this more recently, it was indeed also an old job with the same name that was expected as running but did not ever start due to the fact that it doesn't exist anymore. Try removing it from the branch protection as others have suggested, and then re-add it (after a refresh or similar, to make sure the old job ID isn't cached). This solved the issue completely for me.

Also worth mentioning that the branch protection actions list seems to populate from main/dev only, at least in our setup, so I would make sure you have updated those appropriately.

[alexlovar]

It would be great if the detailed instructions were included too

[nickguo]

For anyone arriving here in the future, my Stuck action problem was resolved by closing and then immediately re-opening the PR.

[handipriyono]

Thanks, it works for me too.!
Close and then re-Open the Pull Request really works and trigger re-running

[arielshaqed]

Is there a better workaround? My merge to master runs a 15-minute CI for this particular PR (hint: testing on Azure is slow), and I prefer to wait less in future.

[nickguo]

@arielshaqed No better workaround to my understanding because if the PR is stuck on "Waiting for status...", most likely your CI never triggered in the first place.

[lemon1964]

test Expected — Waiting for status to be reported

The rule is on the main branch.
And the process is on the develop branch.

Changed main to develop in the rules.
The rule check passes immediately