Is a request ID issued to the request by the time this happens? I don't see the exact sequence of events, but I wonder if this leads to races where a request ID never gets returned to the pool of available ones.

That's a good point, we cannot return the connection because it hasn't been borrowed yet. It won't necessarily be lost since it will be returned when the response comes back. Ideally we would cancel sending it at this point but that doesn't seem easy.

Pushed up a changelog update. We'll need to rebase onto master before merge, but I just want to see what the unit tests look like.

But I think I agree, this doesn't solve the issue -- if self._connection can be None at self._connection._requests.pop(self._req_id), it can be None at with self._connection.lock:, right?

Maybe what we want is a rescheduling solution -- I'll try something like

if self._connection is None:
    self.session.cluster.connection_class.create_timer(0.01, self._on_timeout)
    return

Seems like this was solved with #899 so closing this.

Awesome, thanks for the cleanup.