{"action":"opened","issue":{"url":"https://api.github.com/repos/fsouza/go-dockerclient/issues/478","repository_url":"https://api.github.com/repos/fsouza/go-dockerclient","labels_url":"https://api.github.com/repos/fsouza/go-dockerclient/issues/478/labels{/name}","comments_url":"https://api.github.com/repos/fsouza/go-dockerclient/issues/478/comments","events_url":"https://api.github.com/repos/fsouza/go-dockerclient/issues/478/events","html_url":"https://github.com/fsouza/go-dockerclient/issues/478","id":138998826,"number":478,"title":"Unexpected behavior of AttachToContainerNonBlocking","user":{"login":"cezarsa","id":11041,"avatar_url":"https://avatars.githubusercontent.com/u/11041?v=3","gravatar_id":"","url":"https://api.github.com/users/cezarsa","html_url":"https://github.com/cezarsa","followers_url":"https://api.github.com/users/cezarsa/followers","following_url":"https://api.github.com/users/cezarsa/following{/other_user}","gists_url":"https://api.github.com/users/cezarsa/gists{/gist_id}","starred_url":"https://api.github.com/users/cezarsa/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cezarsa/subscriptions","organizations_url":"https://api.github.com/users/cezarsa/orgs","repos_url":"https://api.github.com/users/cezarsa/repos","events_url":"https://api.github.com/users/cezarsa/events{/privacy}","received_events_url":"https://api.github.com/users/cezarsa/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-03-07T14:56:18Z","updated_at":"2016-03-07T14:56:18Z","closed_at":null,"body":"If one wants to mimic the behavior of the `docker run` command using go-dockerclient a common approach would be:\r\n```go\r\nclient.CreateContainer()\r\nopts := AttachToContainerOptions{OutputStream: buffer}\r\nwaiter := client.AttachToContainerNonBlocking(opts)\r\nclient.StartContainer()\r\nwaiter.Wait()\r\nprintln(\"container output:\", buffer.String())\r\n``` \r\n\r\nHowever, this code is wrong. There's a chance that the container will be started and finished before the attach request is even made. This happens because `AttachToContainerNonBlocking` returns before the attach request is sent to the docker server. To fix this behavior the correct approach would be:\r\n```go\r\nclient.CreateContainer()\r\nopts := AttachToContainerOptions{OutputStream: buffer, Success: make(chan struct{})}\r\nwaiter := client.AttachToContainerNonBlocking(opts)\r\n<-opts.Success\r\nclose(opts.Success)\r\nclient.StartContainer()\r\nwaiter.Wait()\r\nprintln(\"container output:\", buffer.String())\r\n``` \r\n\r\nIn this case, the `Success` channel is used to let the user know that the request have already been sent to docker and we're attached to the container. It's not clear, though, that using this channel is needed when attaching to a container with the purpose of capturing its output. This may trick a lot of users into having inconsistent responses from containers. (I for one have been tricked before)\r\n\r\nI propose that we change the `AttachToContainerNonBlocking` method to only return after ensuring that go-dockerclient is already attached to the container. This could be done in a backwards compatible way by only waiting for attaching if `opts.Success` channel is `nil`. If it's not nil it's possible that the user is already doing the right thing."}}