The Asynchronous Authorized Session API needs to support max_allowed_time as a parameter to the request method, to allow users to configure the total method execution time i.e. if the method is run longer than this, then a timeout exception is raised.
An asynchronous timeout context manager can be implemented to support this, similar to google.auth.transport.requests.TimeoutGuard which will enforce timeout on an asynchronous block of code using asyncio.wait_for() and keep the timeout logic separate from the core AuthorizedSession.request API logic.
Why do we not re-use the synchronous timeout guard?
- to keep the sync and async code paths separate.
- It is implemented specifically to support the timeout type for the underlying
requests API i.e. a tuple.
- It will not enforce timeout on an async block of code and will not raise an exception until the async block of code has completed.
The Asynchronous Authorized Session API needs to support max_allowed_time as a parameter to the
requestmethod, to allow users to configure the total method execution time i.e. if the method is run longer than this, then atimeoutexception is raised.An asynchronous timeout context manager can be implemented to support this, similar to google.auth.transport.requests.TimeoutGuard which will enforce timeout on an asynchronous block of code using
asyncio.wait_for()and keep the timeout logic separate from the coreAuthorizedSession.requestAPI logic.Why do we not re-use the synchronous timeout guard?
requestsAPI i.e. atuple.