Repository navigation
the down method doesn't appear to work #186
Description
After having run the following command:
await compose.upAll(composeOpts)
I run the following command:
await this.compose.down(composeOpts)
and he enclosing promise simply dies. I have wrapped this code in a try and it doesn't catch any error. The execution just stops.
Is there an example of down being used somewhere? I can't find any documentation on down or stop, and I am unable to manage my containers after creating them with this package.
Reacted by Reece Daniels and Olga
Activity
Steveb-p commentedon Oct 16, 2021
@KenEucker you can see it being tested here:
docker-compose/test/index.test.ts
Lines 194 to 202 in dd4fe76
In most cases if your promise is not executed, it's because the calling code was not adjusted for async execution. For example:
would not do anything, because there was nothing attached to the promise handlers (
.then). Depending on the javascript engine and how long the process lasts after creating the promise it may or may not execute.Make sure that the calling code handles the promise. For example:
KenEucker commentedon Oct 16, 2021
@Steveb-p I am handling the promise, in this way:
Steveb-p commentedon Oct 16, 2021
@KenEucker to be honest, I have no idea. If you look into the source code all we do is wrap the process of
docker-composeand wait for it to exit:docker-compose/src/index.ts
Lines 190 to 197 in dd4fe76
I haven't worked in NodeJS for quite a while, but promises should either resolve or reject, and it's handled internally by the engine (by putting it into the loop's queue). The fact that nothing gets executed is curious.
I assume that the whole process ends and that's the only thing that it's supposed to do? There are no calls to
process.exitand so on? Or is it a part of a bigger process end it simply does not do anything?It's possible that there is some sort of confirmation prompt that
docker-composewaits for. That would make the child process hang without resolving 🤔Can you log the stdout/stderr somewhere?
KenEucker commentedon Oct 16, 2021
@Steveb-p thank you for trying to help!
I am not making any calls to process.exit, this code executes upon SIGINT. The 'exit' event code that you linked is also never reached when calling .down.
I can try to dig more into the internals of docker-compose, I guess. I downloaded the source code and tried running the tests that you referenced but they don't work for me. I get a
No tests found, exiting with code 1.AlexZeitler commentedon Oct 17, 2021
@KenEucker Which Node.ja version do you use on which platform? I’m using
docker-composeincludingdownheavily at an internal project right now and it works (local machine macOS and GitHub CI). Whichdocker-composeversions do you use (this package and CLI)?KenEucker commentedon Oct 17, 2021
@AlexZeitler running node 16.10, Mac OS 11.6, and the latest docker-compose.
AlexZeitler commentedon Oct 17, 2021
Tests seem to be ok on node 16.10, I'm also on macOS 11.6:
Steveb-p commentedon Oct 17, 2021
Does the process "hang" until interrupted, or does it simply exit after calling
.down?KenEucker commentedon Oct 17, 2021
@Steveb-p the process doesn't hang, it just "exits" that async method, almost as if the promise resolved, and continues executing the lines after "bringItDown" is called.
@AlexZeitler I cloned anew, yarn install and yarn test, and now the tests are being found and completed successfully. I will try to use the tests here to narrow down the cause of my issue.
Steveb-p commentedon Oct 17, 2021
This for me means that it's almost certain that the subprocess was created and it never exited. It fits your description. That's the only situation where this particular promise would be left without resolution, because the promise is resolved only when the subprocess exits. I'd suggest attaching an output stream and seeing exactly what it says. My guess would be that it's waiting for a confirmation.
console.logcalls from your example are never executed, because the promise never resolves.Code after
bringItDownfunction is executed, because it's asynchronous. I can only assume that you actually do not wait for the promise to be resolved.KenEucker commentedon Oct 18, 2021
@Steveb-p I will share my exact code, in hopes that it isn't too confusing. Here's the code I am using for two separate docker environments, being loaded separately, and calling upAll (not shown below, as that part does work). I know that my WordPress container starts but my Redis does not (simple port collision). I can access the WordPress installation (pictured below) when the application is running.
The
closemethods are called upon exit, or SIGINT, and is the code I have been discussing here.redis
wordpress
You can see from my logs, that WordPress starts, Redis does not. You can also see that upon close, the issue I am experiencing through the logs.
Accessing the WordPress installation:
The
🤖 Stopped 🤖message comes from the main application which is calling each of theclosemethods, demonstrating that the application continues sequentially as expected (because of async/await) before ending as expected.After resolving the port issue with Redis, you can see from the change in logs the same experience as the WordPress container.
The docker containers have been started and remain up after closing my application:
I am unsure how to add more logging to this situation, or how to attach an output stream to this specific code. I won't ask for your assistance in this area, but I do feel comfortable trying to follow an example of such being done with the source code for this project as I can now get the tests to run.
Again, I appreciate the help and suggestions.
AlexZeitler commentedon Oct 18, 2021
Not sure if this is an issue (never tried this) but you're using
awaitandthentogether.Steveb-p commentedon Oct 18, 2021
Technically this should not change much,
awaitis basically aGeneratorwrapper around.thenand.catchcalls. Since.thenreturns aPromise, it should work exactly as we expect here.I've looked it up and apparently you can't do that (attach the streams) atm. That's because
docker-compose/src/index.ts
Lines 167 to 170 in dd4fe76
doesn't allow passing other options to the spawned process 😕 I kinda assumed it was possible.
See
child_process.spawnreference: https://nodejs.org/api/child_process.html#child_process_child_process_spawn_command_args_optionsWe're looking for
stdiooption.I'll have a look if we can patch this after work.
rubengmurray commentedon Sep 26, 2022
@Steveb-p did you find a solution to this? I'm also seeing issues with
.down(). I run mine at the end of an entire mocha test suite, on Node14.18.2. My experience is that the process hangs; if I put a log before the await, and after the await, only the log before theawaitprints... and then nothing even after minutes of waiting...docker-compose:0.23.17I just went through the process of upgrading the service in question to
16.10.0as mentioned above, and I get the same experience.To sanity check I ran
docker compose downvia the cli in the folder in question and it tore down the containers immediately.rubengmurray commentedon Sep 26, 2022
For additional context:
During the
mochatest suite, at the beginning I runupAll; two global hooks, one tosetup, and the other toteardownat the end.The
upAllworks every time, thedownnever works. One thing I have noticed is that the child process spawned by thedowncommand has apid: undefinedif you log out thechild_process. I can't see that this is a good thing, and I wonder therefore if this process even starts?For the time being, I've just gone with this as a workaround as my teardown: