Note that we had been using the ContainerWait API prior to Docker 1.13.0 It was changed to use the Events API along with the PR which moved AutoRemove to be handled by the daemon. Take a look at the comment thread of that PR (around here #20848 (comment)) to see the discussion of how we ended up using the Events API. I think there was some confusion about it - it was not necessary to switch from the ContainerWait API to using the Events API because we start the wait after creating the container but before starting it which should greatly reduce the edge case they were discussing in that PR.

ping @tonistiigi @mlaventure PTAL

Actually, I don't think this works the way I expect ... Apparently the ContainerWait API returns immediately if the container state is created. I expected it to block but instead it behaves as if the container has finished. Is this intended?

This conflicts with the comment on that function which says:

WaitWithContext waits for the container to stop

https://github.com/docker/docker/blob/36d6d76a41be4973eed98f64a565f8cf92dc16e0/container/state.go#L199

How does this handle the waitRemove case where the event is not die but destroy?

How does this handle the waitRemove case where the event is not die but destroy?

The intention is to not use events at all, but just wait for the container to exit. The client will know (depending on the API version being used) whether it is responsible for deleting the container when waitRemove is true.

@jlhawn But if client is not responsible for deleting the container it needs to wait until daemon has cleaned it up. Otherwise, things like docker run --rm --name foo && docker run --name foo will start giving errors.

oh I see, so the destroy event is to wait for the container to be removed? Well, then it's not the same as ContainerWait since that's only designed to wait for the container process to exit.

I did push for semantics changes for /wait in the original PR for this. I was not aware of the issues with swarm-classic though. If they are serious, we can bring back that discussion.