[Bug]: yarn install hangs at Resolution Step

[Peiprjs]

Self-service

• I'd be willing to implement a fix

Describe the bug

When running yarn install or just yarn, the installer seems to hang at one package during the Resolution Step, seemingly using 0 resources overall. This happens on version 3.2.0, when using both public and private sources (all of them are public, only one is private), hanging always on a public package, not always the same though, but it seems to cycle through them. Making the system wait before installation seems to get it farther in, but it fixees nothing.
The packages install fine using npm.

To reproduce

Remove the lockfile and run yarn with a lockfile that contains 1987 packages, one of them from a private repo requiring SSH authentication.

Environment

System: 
OS: Linux 5.16 Parrot OS 5.0 (Electro Ara) 5.0 (Electro Ara) 
CPU: (4) x64 Intel(R) Celeron(R) N4120 CPU @ 1.10GHz 
Binaries: 
Node: 16.14.2 - /tmp/xfs-16d9b8e0/node 
Yarn: 3.2.0 - /tmp/xfs-16d9b8e0/yarn npm: 8.6.0 - ~/.nvm/versions/node/v16.14.2/bin/npm

Additional context

No response

[xeger]

I'm seeing similar behavior while invoking yarn install inside a container. It doesn't happen on my Linux or Mac OS host systems.

Specifically, I see yarn hanging after the end of the resolution step.

➤ YN0000: ┌ Resolution step
[various peer dependency warnings]
➤ YN0000: │ Some peer dependencies are incorrectly met; run yarn explain peer-requirements <hash> for details, where <hash> is the six-letter p-prefixed code
➤ YN0000: └ Completed in 0s 566ms

I have isolated the issue; it is an endless-loop bug in [email protected] which is used by [email protected]. The bug also manifests in the latest version of [email protected] so it looks like Yarn is depending on a fundamentally buggy tool.

I'll file a new yarn issue to recommend that Yarn use some sort of timeout, or otherwise guard against runaway diff, or give us a way to opt out of diffing.

[yarnbot]

Hi! 👋

This issue looks stale, and doesn't feature the reproducible label - which implies that you didn't provide a working reproduction using Sherlock. As a result, it'll be closed in a few days unless a maintainer explicitly vouches for it or you edit your first post to include a formal reproduction (you can use the playground for that).

Note that we require Sherlock reproductions for long-lived issues (rather than standalone git repositories or similar) because we're a small team. Sherlock gives us the ability to check which bugs are still affecting the master branch at any given point, and decreases the amount of code we need to run on our own machines (thus leading to faster bug resolutions). It helps us help you! 😃

If you absolutely cannot reproduce a bug on Sherlock (for example because it's a Windows-only issue), a maintainer will have to manually add the upholded label. Thanks for helping us triaging our repository! 🌟

[mklueh]

I was facing this issue in GitHub Actions. The reason was, I was using yarn berry but my yarn.lock file was still of version 1.

Instead of failing, it just freezes

[ssbarnea]

I am encountering the same issue with latest yarn and it reported "Completed in 2m 25s" but you do not really get any feedback that is doing anything. I was not able to spot a CPU spike either. I do suspect that it might be caused by some networking throttling on the server side (npm.org) but I have no proof as no logging happens. If one or two requirest need to timeout (likely 30s default) it might explain why it get "stuck".

[kubijo]

This is still an issue with yarn 4.0.1 … even with nothing fancy configured:

cacheFolder: ./.yarn/cache

compressionLevel: mixed

defaultSemverRangePrefix: ""

enableGlobalCache: false

logFilters:
  - code: YN0013
    level: discard

nodeLinker: node-modules

yarnPath: .yarn/releases/yarn-4.0.1.cjs

What I do is run yarn upgrade-interactive, select a few dependencies, confirm and get stuck at:

➤ YN0000: · Yarn 4.0.1
➤ YN0000: ┌ Resolution step

At this point it can't even be killed by ctrl+c or ctrl+d and I have to sigkill that.
This is on node node v20.4.0

[kubijo]

Ok, so it eventually finishes and the resolution step alone took 6m 54s

[kubijo]

Also, it does not seem to be connected strongly to a number of selected packages… I just tried it with like three times as many and it took 6m37s

[cjsewell]

I have this issue too, can take over 4 minutes

➤ YN0000: · Yarn 4.0.1
➤ YN0000: ┌ Resolution step
➤ YN0085: │ .....
➤ YN0000: └ Completed in 4m 60s
➤ YN0000: ┌ Post-resolution validation
➤ YN0060: │ ....
➤ YN0002: │ ....
➤ YN0086: │ Some peer dependencies are incorrectly met; run yarn explain peer-requirements <hash> for details, where <hash> is the six-letter p-prefixed code.
➤ YN0000: └ Completed
➤ YN0000: ┌ Fetch step
➤ YN0013: │ 2 packages were added to the project, and 2 were removed (- 146.86 KiB).
➤ YN0000: └ Completed in 3s 102ms
➤ YN0000: ┌ Link step
➤ YN0008: │ .... must be rebuilt because its dependency tree changed
➤ YN0000: └ Completed in 0s 971ms
➤ YN0000: · Done with warnings in 5m 4s

  System:
    OS: Linux 6.5 Ubuntu 23.10 23.10 (Mantic Minotaur)
    CPU: (20) x64 13th Gen Intel(R) Core(TM) i9-13900H
  Binaries:
    Node: 18.18.2 - /tmp/xfs-d86194ec/node
    Yarn: 4.0.1 - /tmp/xfs-d86194ec/yarn
    npm: 9.8.1 - ~/.nvm/versions/node/v18.18.2/bin/npm
    pnpm: 8.9.2 - ~/.nvm/versions/node/v18.18.2/bin/pnpm
    bun: 1.0.7 - ~/.bun/bin/bun

[edoardo-bluframe]

Same here

2m 3s

I have a pretty big monorepo and I just have to guess it has to with that. It started with yarn berry a few versions ago

Can we figure out why this is happening? 😄

[arcanis]

Can one of you provide us with a reproduction case in a new issue? It's possible you trigger some sort of pathological case, but it's impossible to say without looking at the same thing.

[arty-name]

package.json
yarn.zip
Copying these two files into a new folder and running yarn upgrade-interactive in it, and selecting the first package to upgrade does it for me. Some other combinations of packages to upgrade have the same effect. Yarn 4.0.1 via corepack, node 20.9.0

[arty-name]

I’ve run it with --inspect and tried to pause the execution in the debugger, but it only stopped after a long time in this function:

        function YI(t, e) {
            for (let r of t) {
                let o = e(r);
                if (o !== dne)
                    return o
            }
        }

being called from

        function Kst() {
            if (process.platform === "darwin" || process.platform === "win32")
                return null;
            let e = (process.report?.getReport() ?? {}).sharedObjects ?? []
              , r = /\/(?:(ld-linux-|[^/]+-linux-gnu\/)|(libc.musl-|ld-musl-))/;
            return YI(e, o=>{ ...

The values in t were:

[
    "linux-vdso.so.1",
    "/lib/x86_64-linux-gnu/libdl.so.2",
    "/lib/x86_64-linux-gnu/libstdc++.so.6",
    "/lib/x86_64-linux-gnu/libm.so.6",
    "/lib/x86_64-linux-gnu/libgcc_s.so.1",
    "/lib/x86_64-linux-gnu/libpthread.so.0",
    "/lib/x86_64-linux-gnu/libc.so.6",
    "/lib64/ld-linux-x86-64.so.2",
    "/lib/x86_64-linux-gnu/libnss_mdns4_minimal.so.2"
]

[arty-name]

Somehow this is the getReport function taking up 6.5 minutes when called from yarn. When I call it directly in node it returns immediately 🤷

[arty-name]

Looks like this is a manifestation of Node bug nodejs/node#46060

[arty-name]

Oh, right, this bug becomes a duplicate of #5167