Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

I signed it!

@fabriziodemaria

@jonparrott Could you take a look at this PR please?

5 minutes seems way too high. App Engine will terminate requests after 60 seconds.

@jonparrott I wanted to be conservative.

I've changed it to 60s now.

@i-maravic I guess my concern here is that I don't like the idea of using any library-specific timeout that the user doesn't explicitly set. It's surprising behavior. What prompted this change? Can I get some more context to better understand what problem this is trying to solve?

@jonparrott We're using google-api-python-client when running periodic (hourly or daily) batch jobs for uploading to BigQuery and reading/writing to Google Cloud Storage. All the periodic jobs are being executed in Docker containers.

Recently we've experienced issues with those jobs hanging forever without making any progress. After doing some investigation we detected that the code making requests to Google APIs (aka. google-api-python-client) is hanging forever while waiting something to read from TCP socket. This was surprising behaviour for us.

After doing even more digging we discovered that Docker had some weird networking issues, which were causing this in the first place. We're not 100% sure how to reproduce Docker issue though, but restarting the Docker service mitigated a lot of problems we're experiencing.

I fell that library doing HTTP requests should set a sane default timeout for doing HTTP requests, because we could easily avoid issues like this in the future. I would argue that this is what most of the users would like to have any how.

I would also like to point out that you already have code in your lib, which is dealing with Timeout exceptions that might be thrown from the HTTP requests and do the retries accordingly.

I know that you're not using requests library, but there is very nice explanation why all production code using it should set timeouts for all the HTTP requests it's doing.

@i-maravic I see, okay.

I need the CLA bot to verify your signature status before I can merge.

I work for Spotify. Spotify should have signed the CLA.

@i-maravic gotcha.

@lukesneeringer @landrito I'd appreciate if one of you could chime in and let me know your thoughts before I merge this.

A 60 second default timeout seems reasonable to me, and it is easy enough to override. LGTM.

@lukesneeringer thanks for chiming in!

@i-maravic okay, so it looks like this is going to happen, can I ask two things of you:

1. Is it possible to add tests or assertions to existing tests to cover this?
2. This timeout only applies to the http object used to fetch discovery documents. Do you want to apply the timeout to the http object used to make actual API requests as well?

@jonparrott Sounds like reasonable asks.

Could you point me out where is the http object for actual API requests constructed?

@i-maravic just below in build_from_document: https://github.com/google/google-api-python-client/pull/320/files#diff-bceb3b293cf7c789403d137d70ef8dd3R370

@jonparrott Now the default timeout is applied to all discovery and API requests (auth or not)

Hopefully I did catch all httplib2.Http() instantiations in the lib.

@i-maravic this looks good, one last question:

Do you want to pass in timeout to authorized_http here? Otherwise, the authorized http instance won't have the timeout.

@jonparrott authorized_http gets timeout set here

@i-maravic gotcha. Alright, this LGTM. Thanks!