--success last does not work while --success first does

[sergeyevstifeev]

Expectation
Switching the order of two commands while simultaneously switching from --success last to --success first should not change the exit status of concurrently

Observed behaviour
--success last does not work as expected when used together with --kill-others

Version
4.1.0

Steps to reproduce
Take two commands: sleep 5; exit 0; and sleep 100, and switch their order. With --success first works correctly:

$> concurrently --kill-others --success first 'sleep 5; exit 0;' 'sleep 100'
[0] sleep 5; exit 0; exited with code 0
--> Sending SIGTERM to other processes..
[1] sleep 100 exited with code SIGTERM
$> echo $?
0

With --success last works incorrectly (expected to get exit code 0 same as above):

$> concurrently --kill-others --success last 'sleep 100' 'sleep 5; exit 0;'
[1] sleep 5; exit 0; exited with code 0
--> Sending SIGTERM to other processes..
[0] sleep 100 exited with code SIGTERM
$> echo $?
1

[jcollum-nike]

Maybe this is what I'm seeing right now...

[jcollum-nike]

YEP! Changing the order of commands fixed the issue I was seeing.

4.1.0

[wilgert]

We are running into the same problem. Switching the order of commands helps but we are afraid that it introduces unstable behavior.

[jcollum-nike]

maybe you need a pre script for the thing that definitely needs to happen first?

[RynatSibahatau]

I have the same issue for both first and last on 4.1.0. Seems there is no issue in 4.0.1.

[jcollum-nike]

I think this might be related #187

[gustavohenke]

Hello all! I'm sorry that I took this long to reply.

I think there's a misconception with how --success works.
From its description:

-s, --success     Return exit code of zero or one based on the success or
                  failure of the "first" child to terminate, the "last child",
                  or succeed only if "all" child processes succeed.
                            [choices: "first", "last", "all"] [default: "all"]

Please pay special attention to the first child to terminate part.
Although @sergeyevstifeev showed that he inverted the order of his commands, they are still exiting in the same order.

[gustavohenke]

Does the above help anyone? 🙂

[sergeyevstifeev]

@gustavohenke Ah, I see, this makes sense now. A bit hard to understand from the description, since "first" can be both time-wise and order-wise 🙂

[gustavohenke]

Maybe first-specified/last-specified (or better names!) could be made options for --success?

[jcollum-nike]

I'd like it if I could specify which process is the exit code I care about, --exit=2 or something (3rd process in array is the one I care about)

[gustavohenke]

That SGTM too -- make --success accept a number, which refers to the process index.

[jcollum-nike]

I'd be happy with

• --success=2 means the 3rd item in the array is the one that sets the exit code
• --success=all: any non-zero exit code will result in a non-zero exit code for the group of processes
• (not set): exit codes are irrelevant / ignored

[gustavohenke]

• (not set): exit codes are irrelevant / ignored

Hmm that's a breaking change. The default is all.

Anyway, I'm happy to review PRs for this 🙂

[paescuj]

Implemented by #318 which has been released in v7.2.0.