AuthorizedSession's _auth_request sub-session is never cleaned #658
Labels
priority: p2
Moderately-important priority. Fix may not be included in next release.
🚨
This issue needs some love.
type: bug
Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Environment details
google-auth
version: 1.24.0Steps to reproduce (kinda)
Py.test 6.2 enables hard errors on unhandled thread exceptions and resource errors such as leaking SSL sockets/sockets/FDs. I've spent the last couple hours debugging various
warnings, and digging deep into
google.auth
, I found this problematic segment.As you may be aware,
requests.Session()
objects should be.close()
d (or used as context managers) so the underlying connection pool gets shut down.The above-linked code path creates a separate
requests.Session()
and agoogle.auth.transport.requests.Request
object using it when no explicitRequest
object is passed in (and this seems to be the default for a trivial use of e.g.google-cloud-storage
).When that happens, the secondary session (only used for refreshing credentials) is never cleaned up even if the owning session might be.
Aside on spurious logging
As an aside, this same code path causes a
message to be logged since the sub-session's HTTP adapter is initialized with
max_retries=3
; this is indeed what the requests manual says, but changing that tomax_retries=Retry(3, redirect=True)
(whereRetry
comes fromurllib3
) would fix that.Remedy
I think
AuthorizedSession
should remember whether it initialized this subsession, and if it did, have it clean it up onclose()
; something likemight do since
close()
is already automatically called byrequests.Session.__exit__()
, so careful users ofAuthorizedSession
will benefit from this immediately.I'm willing to formalize this into a PR if the plan sounds good.
Workaround
I'm currently making sure to close those pools with a hack like this.
The text was updated successfully, but these errors were encountered: