I noticed that my workflow files didn't specify what node version to use for this workflow through any node-version or node-version-file. By adding that, and upgrading my project to use node 20, this issue seems to go away.

Thank you for detailed description of the issue! We'll investigate it and come back with details.

I noticed that my workflow files didn't specify what node version to use for this workflow through any node-version or node-version-file. By adding that, and upgrading my project to use node 20, this issue seems to go away.

My workflows do always specify node-version but the post-action is slow as well.

I also have a flow log here which despite requesting lts/iron resolved 20.8.1 which isn't lts/iron. This particular setup-node use is from a reused worflow, when setup-node is used outside of a reused workflow the correct 20.9.0 is resolved.

Just want to report the same thing, from 5s -> 2m15s (Node 18)
Previous: https://github.com/specfy/stack-analyser/actions/runs/6664890448/job/18113374316
With the upgrade: https://github.com/specfy/stack-analyser/actions/runs/6664871105/job/18113316689?pr=84

Same here in multiple projects using JS with Yarn. The Post Setup Node.js job slows down from a few seconds to about 2:20 minutes after upgrading to v4.

It seems to me that this only happens when JS dependencies have been updated. Re-running the job (which causes a cache hit) is fast again - perhaps because the cache doesn't need to be saved.

My conclusion: Saving the cache is significantly slower with v4 than with v3.

Noticing this as well because I have an aggressive timeout-minutes: 1 on my actions/setup-node step, which is now causing many of my builds to fail.

I concur with @ledermann that the issue is somewhere in cache-saving.

With a cache hit, the post-action takes 0s as expected:

Without a cache hit, when trying to save the cache, the post-action times out:

See ruby/setup-ruby#543 which explains a possible cause and fix.

And here's the fix: ruby/setup-ruby@036ef45 that should probably be ported to setup-node

@nikolai-laevskii I opened a PR in #907 that applies the same fix as https://github.com/ruby/setup-ruby (issue ruby/setup-ruby#543, PR ruby/setup-ruby#546), could you take a look at it?

I'm also experiencing this on Node 18.

I'm also experiencing this on Node 18.

@nrutman Actually this issue does not depend on the Node version you're using, but rather the Node version that the GitHub Action runner uses itself (in this case, the runner for @actions/http-client, used by @actions/cache, itself used by @actions/setup-node). We have no control over this other than downgrading to v3 of the action.

Hello everyone. We've merged the fix for the issue. Could you please try to use actions/setup-node@main to confirm that it works as expected?

Made a typo in that commit 😅 . I'll let you know if it appears to be working or not. It doesn't always have the issue but I'll try to run the action a few times to make sure.

Hello everyone. We've merged the fix for the issue. Could you please try to use actions/setup-node@main to confirm that it works as expected?

Hi! Yeah, from some quick tests it seems to work better now.

@dmitry-shibanov Just confirming that the fix has worked for us too

We only really noticed it on Windows where all those tiny node_modules really affect performance:

Before

After

@dmitry-shibanov Can you release the changes?

Hello everyone. We released the changes yesterday.

For now I am going to close the issue. If you have any concerns feel free to ping us.

• I am using v4 with node 20. And it basically hangs forever, any idea how to fix it ?

Issue was related to cmd failing, and for some reason NODE action hanged...once I fixed other issue, it works again. SRY to bother

Hi all. I think I am still affected by this issue.

In my app, the "Post Cache node_modules" step takes quite long for some reason (2m on average). As a result, if I install or remove a yarn dependency, the setup job alone takes around 3 minutes before any other job can start, while if I don't change any deps, it takes only 10 seconds, which is great and expected.

But I would still like not to slow the process down when deps change. Is the behavior I described expected and is there anything I can do? I already changed actions/setup-node@v4 to actions/setup-node@main in my GH workflow.

Here's a link to one of the slow setup runs: https://github.com/domhhv/habitrack/actions/runs/11651863472/job/32442340624.