open-cli-tools / concurrently

Run commands concurrently. Like `npm run watch-js & npm run watch-less` but better.
https://www.npmjs.com/package/concurrently
MIT License
6.98k stars 227 forks source link

Concurrently crashes leaving processes running when piping command exits #230

Open idrise opened 4 years ago

idrise commented 4 years ago

Recreate

concurrently --kill-others -n api,ui \"nx serve api\" \"nx serve ui\" | lnav -t

Then press q to quit lnav and this error is reported and both API and UI continue to be served in the background. It would be great if concurrently shut down when the write stream is destroyed.


    setTimeout(function () { throw err; }, 0);
                             ^

Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed
    at Socket.Writable.write (_stream_writable.js:322:17)
    at Logger.log (***/node_modules/concurrently/src/logger.js:107:27)
    at Logger.logCommandText (***/node_modules/concurrently/src/logger.js:74:21)
    at Logger.logCommandEvent (***/node_modules/concurrently/src/logger.js:69:14)
    at SafeSubscriber._next (***/node_modules/concurrently/src/flow-control/log-exit.js:8:25)
    at SafeSubscriber.__tryOrUnsub (***/node_modules/rxjs/internal/Subscriber.js:205:16)
    at SafeSubscriber.next (***/node_modules/rxjs/internal/Subscriber.js:143:22)
    at Subscriber._next (***/node_modules/rxjs/internal/Subscriber.js:89:26)
    at Subscriber.next (***/node_modules/rxjs/internal/Subscriber.js:66:18)
    at Subject.next (***/node_modules/rxjs/internal/Subject.js:60:25)
Emitted 'error' event on Socket instance at:
    at errorOrDestroy (internal/streams/destroy.js:128:12)
    at Socket.Writable.write (_stream_writable.js:324:5)
    at Logger.log (***/node_modules/concurrently/src/logger.js:107:27)
    [... lines matching original stack trace ...]
    at Subscriber.next (***/node_modules/rxjs/internal/Subscriber.js:66:18) {
  code: 'ERR_STREAM_DESTROYED'
}```
gustavohenke commented 4 years ago

Hey @idrise! Thanks for the report. Sounds like an easy fix.

gustavohenke commented 1 month ago

I was looking at this issue - while it does indeed seem like an easy fix, I'm not sure which feedback should concurrently provide. It'd be nice to print the usual "blabla exited with ", however everything goes to stdout. Switching to stderr for the final messages is probably not desirable. Maybe print some kind of error message instead?

idrise commented 1 month ago

I think a clean exit, killing the running processes makes the most sense IMHO. Could be that any throw ends up leaving processes hanging.