Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: yarn workspaces foreach always exits with status 0 even on error #3334

Closed
1 task
akphi opened this issue Aug 23, 2021 · 16 comments
Closed
1 task

[Bug]: yarn workspaces foreach always exits with status 0 even on error #3334

akphi opened this issue Aug 23, 2021 · 16 comments
Labels
bug Something isn't working upholded Real issues without formal reproduction

Comments

@akphi
Copy link

akphi commented Aug 23, 2021

Self-service

  • I'd be willing to implement a fix

Describe the bug

In Yarn@3.0.1, when I run a command with yarn workspaces foreach, it still return as successful even when a workspace process failed.

To reproduce

This is my repro: akphi/issue-repo#1

I setup a test monorepo with 2 workspaces pkg1 and pkg2. Each workspace has a script called doSomething. pkg1 will exit with code 1 since the command error is not known.

At the root directory, if we run the following command, we got some unexpected result:

yarn workspaces foreach run doSomething                                          # no error
yarn workspaces foreach --all run doSomething                                    # no error
yarn workspaces foreach --parallel run doSomething                               # no error
yarn workspaces foreach --all --parallel --topological-dev run doSomething       # error

Environment

System:
OS: macOS 11.5.1
CPU: (8) x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
Binaries:
Node: 14.17.1 - /private/var/folders/95/y32364512q77c1dvhkpnr_n80000gn/T/xfs-02ae3755/node
Yarn: 3.0.1 - /private/var/folders/95/y32364512q77c1dvhkpnr_n80000gn/T/xfs-02ae3755/yarn
npm: 6.14.13 - ~/.nvm/versions/node/v14.17.1/bin/npm
npmPackages:
jest: 27.0.6 => 27.0.6

Additional context

Related to #2486

@akphi
Copy link
Author

akphi commented Sep 2, 2021

@merceyz Following your comment, I gave this another try using Node@16 and I can still reproduce this issue 😕

❯ yarn workspaces foreach --verbose run doSomething
➤ YN0000: [pkg1]: Process started
➤ YN0000: [pkg1]: command not found: error
➤ YN0000: [pkg1]: Process exited (exit code 127), completed in 0s 74ms

➤ YN0000: [pkg2]: Process started
➤ YN0000: [pkg2]: build
➤ YN0000: [pkg2]: Process exited (exit code 0), completed in 0s 53ms
➤ YN0000: Done in 0s 133ms
  System:
    OS: macOS 11.5.1
    CPU: (8) x64 Intel(R) Core(TM) i7-4870HQ CPU @ 2.50GHz
  Binaries:
    Node: 16.8.0 - /private/var/folders/95/y32364512q77c1dvhkpnr_n80000gn/T/xfs-645a3447/node
    Yarn: 3.0.1 - /private/var/folders/95/y32364512q77c1dvhkpnr_n80000gn/T/xfs-645a3447/yarn
    npm: 7.21.0 - ~/.nvm/versions/node/v16.8.0/bin/npm

@yarnbot
Copy link
Collaborator

yarnbot commented Oct 2, 2021

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! 🌟

@yarnbot yarnbot added the stale Issues that didn't get attention label Oct 2, 2021
@akphi
Copy link
Author

akphi commented Oct 2, 2021

@merceyz I'm not familiar with Sherlock enough to reproduce this, could you add the tag upholded to keep this open?

@merceyz merceyz added the upholded Real issues without formal reproduction label Oct 2, 2021
@yarnbot yarnbot removed the stale Issues that didn't get attention label Oct 2, 2021
@remolueoend
Copy link

I initially assumed to have the same issue. Turns out the failing script swallowed the error. At least I've written the corresponding sherlock tests while debugging: Playground

This issue seems not to be reproducible. Any feedback on this @akphi?

@akphi
Copy link
Author

akphi commented Apr 18, 2022

@remolueoend On my machine, I just tried to do do

yarn workspace pkg1 doSomething
# command not found: error

echo $?
127

the exit code is 127 it seems. What do you mean by "the failing script swallowed the error`? Also nice work on the sherlock test!

@remolueoend
Copy link

What do you mean by "the failing script swallowed the error`?

Sorry, that was related to a problem in a personal project and why I investigated this issue in the first place. But based on my personal repository and the sherlock tests, this issue seems not reproducible anymore on the newest version (>= 3.2.0). Can you still reproduce it?

@akphi
Copy link
Author

akphi commented Apr 18, 2022

I just updated to 3.2.0 and tried again, seems like I still get the issue

akphi/issue-repo#4

As said, I think the problem is because the script throws exit code 127 instead of 1. Not so familiar with sherlock myself but when I hit Run it says Non reproducible, I assume it means

await expect(getYarnExitcode(`doSomething`)).toEqual(1)
await expect(getYarnExitcode(`doSomething:all`)).toEqual(1)
await expect(getYarnExitcode(`doSomething:parallel`)).toEqual(1)
await expect(getYarnExitcode(`doSomething:workaround`)).toEqual(1)

are all returning exitcode 1 right? I'm using a Mac, Yarn@3.2.0 and Node@16.13.1 and still can reproduce this error with the example I provided 😢

@remolueoend
Copy link

I assume it means ... are all returning exit code 1?

Yes indeed, and therefore yarn indicates the failure of a subtask correctly. What is the error code in your local repo when running yarn doSomething; echo $? in the root directory? I agree that yarn does not forward the exit code of the failing task (127 in this case), but it still should fail with code 1.

@akphi
Copy link
Author

akphi commented Apr 18, 2022

Supposed, you mean yarn doSomething:workaround. I got

❯ yarn doSomething:workaround; echo $?
➤ YN0000: [pkg1]: Process started
➤ YN0000: [pkg2]: Process started
➤ YN0000: [pkg1]: command not found: error
➤ YN0000: [pkg1]: Process exited (exit code 127), completed in 0s 111ms
➤ YN0000: [pkg2]: build
➤ YN0000: [pkg2]: Process exited (exit code 0), completed in 0s 94ms
➤ YN0000: The command failed for workspaces that are depended upon by other workspaces; can't satisfy the dependency graph
➤ YN0000: Failed with errors in 0s 123ms
1

@remolueoend
Copy link

I actually meant yarn doSomething:standard as you call it in your repo. When I set up the exact same project on my local machine, I get the correct exit code 1 for all 4 commands (standard, all, parallel, and workaround).

@akphi
Copy link
Author

akphi commented Apr 19, 2022

@remolueoend whats your environment like (Node, OS)?

@remolueoend
Copy link

Linux x64 with node v17.7. Can you show us once again the full output when running yarn doSomething:standard; echo $?? And maybe the output of yarn --version. Maybe something's wrong with the resolution of the yarn executable.

@akphi
Copy link
Author

akphi commented Apr 19, 2022

Sure,

❯ yarn doSomething:standard; echo $?
➤ YN0000: [pkg1]: Process started
➤ YN0000: [pkg1]: command not found: error
➤ YN0000: [pkg1]: Process exited (exit code 127), completed in 0s 65ms

➤ YN0000: [pkg2]: Process started
➤ YN0000: [pkg2]: build
➤ YN0000: [pkg2]: Process exited (exit code 0), completed in 0s 34ms
➤ YN0000: Done in 0s 108ms
1

❯ yarn --version
3.2.0

@remolueoend
Copy link

That seems like the expected behavior no? The exit code of yarn workspaces foreach is 1, which indicates a failure.

@akphi
Copy link
Author

akphi commented Apr 19, 2022

@remolueoend omg you're right 😭. So this is no longer a problem anymore 🎉 Thank you so much for your patience!! I'll close the issue here and go to cry since I should have realized this 10 comments ago

image

@akphi akphi closed this as completed Apr 19, 2022
@remolueoend
Copy link

Hey @akphi, no worries, that's why we're here, glad I could help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working upholded Real issues without formal reproduction
Projects
None yet
Development

No branches or pull requests

4 participants