Possible race condition in Remove/wait

https://github.com/docker/docker-py/blob/master/docker/api/container.py
While there is some thread waiting on container on the client side using API
wait(self, container, timeout=None, condition=None)
the container could get removed on the daemon side(auto_remove=true). And the wait throws below error.
Maybe in def remove_container(self, container, v=False, link=False, force=False): we should check if some client is waiting before deleting the container url.
We are seeing this issue intermittently in Airflow , which uses both of these APIs.

Error stacktrace:
File "/opt/sfdc/python36/lib/python3.6/site-packages/docker/api/client.py", line 226, in _post
return self.post(url, **self._set_request_timeout(kwargs))
File "/opt/sfdc/python36/lib/python3.6/site-packages/requests/sessions.py", line 578, in post
return self.request('POST', url, data=data, json=json, **kwargs)
File "/opt/sfdc/python36/lib/python3.6/site-packages/requests/sessions.py", line 530, in request
resp = self.send(prep, **send_kwargs)
File "/opt/sfdc/python36/lib/python3.6/site-packages/requests/sessions.py", line 643, in send
r = adapter.send(request, **kwargs)
File "/opt/sfdc/python36/lib/python3.6/site-packages/requests/adapters.py", line 529, in send
raise ReadTimeout(e, request=request)
requests.exceptions.ReadTimeout: HTTPConnectionPool(host='XXXXXXXX', port=2376): Read timed out. (read timeout=None)

Start with docker/api/container.py, especially wait(self, container, timeout=None, condition=None) and remove_container(self, container, v=False, link=False, force=False), then trace how the client handles a container removed by the daemon. Reproduce the concurrent wait and removal scenario described from Airflow, and consider the issue done when waiting no longer intermittently ends in the reported timeout or equivalent failure.