Open crvarner opened 4 years ago
I'm also getting this bug
My reproduction is more or less this
runwithproxies:
npx concurrently \
--kill-others-on-fail --raw \
-n lightrail,jeanne,drummajor \
-c red,green,blue \
"make buildandrun" \
"proxy --service jeanne --proxy-port 8981 --local-port 8982" \
"proxy --service drummajor --proxy-port 8983 --local-port 8984"
Where the two proxy --service
commands are logging to stdout / stderr
I'm also running into this with concurrently 8.2.2
.
I noticed the issue also manifests when using asyncio
and threading
, not just stacktraces. This makes me wonder if concurrently
is failing to pass the output of deeply nested processes and threads.
Another important clue: the issue doesn't occur when the --raw
flag is used.
@gustavohenke if this doesn't ring any immediate bells, I could put in some time to make a little Python repo with a minimal reproduction.
I think concurrently
has amazing potential for full-stack web development, but this issue kind of ruins the Python experience.
Hey! This issue fell through the cracks. The issue wouldn't happen with raw mode because I/O handling is delegated entirely to the OS. So it must be a bug in concurrently.
@ixxie if you can make a reproduction, that'd be good - the original one doesn't work for me on macOS Sonoma.
Hey! This issue fell through the cracks. The issue wouldn't happen with raw mode because I/O handling is delegated entirely to the OS. So it must be a bug in concurrently.
@ixxie if you can make a reproduction, that'd be good - the original one doesn't work for me on macOS Sonoma.
I've now published a simple reproduction repository which has a minimal Python Uvicorn/FastAPI and a minimal SvelteKit backend.
I've manage to reproduce Unicorn HMR failure and ANSI color code propagation failure. I didn't have luck reproducible the exception tracing error; I suspect it requires some subprocess to run in order to manifest. I'm going to keep trying to reproduce it, and I'll push a new commit if I succeed.
@gustavohenke if you would like I could make a separate issue for the uvicorn HMR crash
Hey, I haven't been able to reproduce either issue on macOS yet. I might take a bit of time to get around running Windows again, so if you feel like venturing into this codebase, I'll review any PRs 😃
As for the colouring issue - seems like python/poetry is disabling colours when its output is piped, so not much that can be done here (seems like FORCE_COLOR
env var isn't respected either)
Hey, I haven't been able to reproduce either issue on macOS yet. I might take a bit of time to get around running Windows again, so if you feel like venturing into this codebase, I'll review any PRs 😃
As for the colouring issue - seems like python/poetry is disabling colours when its output is piped, so not much that can be done here (seems like
FORCE_COLOR
env var isn't respected either)
When you say 'either issue' it sounds like you tried to reproduce two issues, but there are three (delayed stack trace printing, uvicorn HMR crashing the process and color output not propagating). Did you try all three or only two? If so, which two?
I would love to try and dig into the codebase, but I honestly don't even know where I would begin. For us, the HMR issue is critical right now: could you point to where in the codebase I might begin to look to try and resolve this issue?
The other two issues are no longer manifesting for us, perhaps because of the --raw
flag.
When you say 'either issue' it sounds like you tried to reproduce two issues, but there are three (delayed stack trace printing, uvicorn HMR crashing the process and color output not propagating). Did you try all three or only two? If so, which two?
Oh yeah could've been more specific, sorry! I couldn't reproduce the crash nor the delayed stack trace printing. Colouring seems to be related to the piping of output.
could you point to where in the codebase I might begin to look to try and resolve this issue?
Sure, let me try to explain the overall structure that might be significant to you:
Path | Description |
---|---|
https://github.com/open-cli-tools/concurrently/tree/23f97ac412f390a9913f96814da1f4070704d955/src/command-parser | command parsers take the input commands and might modify it or expand it, such as an wildcard transforming npm:server-* to several npm run server-<something> commands. Could theoretically modify the env vars a command receives, its prefix colour, etc |
https://github.com/open-cli-tools/concurrently/tree/23f97ac412f390a9913f96814da1f4070704d955/src/flow-control | this is where the several flow controllers live, which handle the main features of concurrently, such as logging, killing/restarting processes and input handling. They receive the list of all commands, and can change a command's streams, for example |
https://github.com/open-cli-tools/concurrently/blob/23f97ac412f390a9913f96814da1f4070704d955/src/spawn.ts | defines the options that might be passed to child_process.spawn() for each command |
https://github.com/open-cli-tools/concurrently/blob/23f97ac412f390a9913f96814da1f4070704d955/src/command.ts | state of a command, which includes metadata (such as name, prefix colour, PID, etc) + its stdio and close streams; |
https://github.com/open-cli-tools/concurrently/blob/23f97ac412f390a9913f96814da1f4070704d955/src/completion-listener.ts | waits for commands to exit and defines whether that was a success (exit code 0) or not based on given a success definition (e.g. first/last command to exit, all, etc) |
https://github.com/open-cli-tools/concurrently/blob/23f97ac412f390a9913f96814da1f4070704d955/src/logger.ts | decorates output from commands and events such as "sending SIGTERM to other processes..." with prefixes and colours |
https://github.com/open-cli-tools/concurrently/blob/23f97ac412f390a9913f96814da1f4070704d955/src/output-writer.ts | where writing to the output stream is actually done. |
https://github.com/open-cli-tools/concurrently/blob/23f97ac412f390a9913f96814da1f4070704d955/src/concurrently.ts | Orchestrates all of the above. |
Concurrently is structured in a quite OOP way, with interfaces that are implemented by all of the command parsers and flow controllers and they're called in sequence. Each file usually does only one thing, so it should be easy to find what you need to change given the above table.
Good luck!
concurrently version: 5.3.0
Starting webpack and flask app via
npm start
and the following scripts inpackage.json
the flask app contains the following lines:
repeating the request that executes these lines results in the following log output:
Note the stacktrace was only logged once. terminating command vi CTRL-C results in the missing traces being logged:
Concurrently logs traces correctly when the
--raw
flag is set. Any ideas whether this is user error or a bug?reproduction: https://github.com/crvarner/concurrently_bug.git