the down method doesn't appear to work #186
Comments
|
@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: function doSomething() {
compose.down()
}
doSomething()would not do anything, because there was nothing attached to the promise handlers ( Make sure that the calling code handles the promise. For example: function doSomething() {
return compose.down()
}
doSomething().then(() => console.log('done')) |
|
@Steveb-p I am handling the promise, in this way: async function bringItDown() {
try {
console.log('container closing')
await compose.down(composeOpts).then((result) => {
console.log({result}) // never executes
})
console.log('container closed') // never executes
} catch (e) {
console.log('container errored', e) // never executes
}
}
...
// from another async method:
await bringItDown() |
|
@KenEucker to be honest, I have no idea. If you look into the source code all we do is wrap the process of 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 It's possible that there is some sort of confirmation prompt that |
|
@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 |
|
@KenEucker Which Node.ja version do you use on which platform? I’m using |
|
@AlexZeitler running node 16.10, Mac OS 11.6, and the latest docker-compose. |
|
Tests seem to be ok on node 16.10, I'm also on macOS 11.6: |
Does the process "hang" until interrupted, or does it simply exit after calling |
|
@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. |
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.
Code after |
|
@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 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 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. |
|
Not sure if this is an issue (never tried this) but you're using |
Technically this should not change much,
I've looked it up and apparently you can't do that (attach the streams) atm. That's because Lines 167 to 170 in dd4fe76 doesn't allow passing other options to the spawned process 😕 I kinda assumed it was possible. See We're looking for I'll have a look if we can patch this after work. |
|
@Steveb-p did you find a solution to this? I'm also seeing issues with console.log('stopping docker');
await dockerCompose.down();
console.log('stopping docker2');
I just went through the process of upgrading the service in question to To sanity check I ran |
|
For additional context: During the The For the time being, I've just gone with this as a workaround as my teardown: |
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.
The text was updated successfully, but these errors were encountered: