Closed odeadglaz closed 5 months ago
Rethinking on this, this change includes also an edge case that doesn't work:
---> It will resolve altho the first command is also alive
So I might be going on the wrong direction here would love to here your tought on the initial design of the start
/kill
API, were they meant to be used this way?
Another option would be a design-level change such as:
Adding a new restart
API for command which goes something like:
restart(code? :string) {
this.state = 'restart'; // New CommandState
this.kill();
this.start();
}
And a modification for Command.start
for skipping emitting close event if the command state equals to restart
Would love to hear your mind on it 👍
So how would u recommend proceeding? Do you wish to have this fix for now? (as you said just a slight improvement for the current state)
@gustavohenke Not sure why I'm getting inconsistent behavior in tests, did you encounter this kind of behavior in the past? (locally over my mac I can't seem to reproduce it)
Currently, the
CompletionListener
sets abufferCount
upon commands close streams to conclude once commands are finished and then evaluates the exit code and determines thesuccess/fail
conditions.Continued to the issue brought here, calling manually
Command
-kill/start
API's manually, causes a bug where theCompletionListener
resolves before all commands had exited ( as a single command can emit multiple close events ).This PR changes the behaviour to take a single emit event from each command in order to conclude termination.
Disclaimer: Potentially I would love to find a way to take the last exit command emitted from each
Command
tho I couldn't find a way would appreciate any suggestion 👍 mine while I kept things the same.Side effects
completion-listener.spec.ts
file to all use the same command exit helperAllowipc
for spawned commandsResolves: https://github.com/open-cli-tools/concurrently/issues/463