Currently I'm facing some issues with docker compose version v2.15.1 with the stop command:

The command is executed without errors but it seems it didn't stop the container when the command exits because a check in our test fails.

  await compose.stop({ cwd: path.join(__dirname), log: logOutput })
  expect(await isContainerRunning('/compose_test_web')).toBeFalsy() // fails
  expect(await isContainerRunning('/compose_test_proxy')).toBeFalsy()

Putting jest.setTimeout(1000) after the compose.stop call fixes the test but that's a bad solution.

@StefanScherer @Steveb-p can I pick your brains here?

@AlexZeitler Interesting. Is there a simple repro case? I haven't looked into the code, but your failing test would be basically a docker compose up -d with two services, then later the docker compose stop and imediatelly a docker compose ps? And it worked with versions before 2.15.1, right?

I would assume that docker-compose may report a container as stopping, while in reality it is still running. Don't see a reason otherwise. We are waiting for docker-compose process to complete, and adding a timeout fixing it seems to indicate that there is a slight delay between command being run and container being actually stopped.

I would assume that docker-compose may report a container as stopping, while in reality it is still running. Don't see a reason otherwise. We are waiting for docker-compose process to complete, and adding a timeout fixing it seems to indicate that there is a slight delay between command being run and container being actually stopped.

Yes, that's my assumption as well.

A workaround could be to find the services started by the compose file, add dockerode as dependency as we do in the test and retry the check until the services are really stopped and only then return from our function.

A workaround could be to find the services started by the compose file, add dockerode as dependency as we do in the test and retry the check until the services are really stopped and only then return from our function.

Would that involve moving dockerode from a test dependency to a dependency? Without pushing the instantiation of dockerode to the user it may be complex to add it, for example if the user is running a complex docker setup (dind, etc)