As of#967 released in google-cloud-bigquery 3.0.0, the _begin method is no longer used for query jobs.

This was overridden because we wantedresult() from the superclass to calljobs.getQueryResults, not justjobs.get (i.e.job.reload() in Python). Now that we aren't using the superclass forresult(), this method is no longer necessary.

Thought: We probably should have been callingset_exception based on the job status. Need to look into this further.

OK. We are. 😅

Which we call from_set_properties

Which we call fromreload

Uh oh, ifjobs.getQueryResults fails because the job failed it can throw an exception butrestart_query_job will still beFalse.

But we don't wantrestart_query_job = True because sometimes this can raise an ambiguous exception such as quota exceeded, where we don't know if it's the job quota and it's a failed job or at a higher level (Google Frontend - GFE) where the job might actually still be running and/or succeeded.

This isn't the worst way to fail, but it'd be nice to do thejobs.get call above in case of an exception to get a chance at retrying this job if the job failed.

Filed#1903 to track improvements to ambiguous errors.12fa9fb fixes an issue where we weren't actually retrying after an ambiguous failure even though we thought we were.

Whichsuperclass are we discussing here?

google.api_core.future.polling.PollingFuture._DEFAULT_VALUE introduced ingoogleapis/python-api-core#462.

I've updated the comments with some more info as well as some things to consider in case we want to have a default value for timeout in future.

What is the purpose of using 4.0 here?
Can we get a comment indicating why 4.0?

Updated to2.0 * (2.0 * _DEFAULT_RETRY_DEADLINE) and added some explanation both here and inQueryJob.result().

Note: This still only gets us 1 query retry in the face of the problematic ambiguous error codes fromjobs.getQueryResults() but that's better than the nothing that we were actually getting before in some cases. I don't feel comfortable bumping this much further, though maybe 3.0 * 2.0 * _DEFAULT_RETRY_DEADLINE would be slightly less arbitrary at 1 hour?

Not sure I am tracking the relationship between the make connection inputs versus the assert_has_calls checks.

Can you explain how these tests are supposed to work?

make_connection is a convention ingoogle-cloud-bigquery unit tests that actually predates our use of the "mock" package. It mocks out the responses to REST API calls, previously with a fake implementation of our "Connection" class from the_http module and now with a true mock object. For every quest that our test makes, there should be a corresponding response. As withMock.side_effect, any exceptions in this list will be raised, instead.

I'm guessing your question also relates to "Why thisparticular set of requests / responses?". I've added some comments explaining why we're expecting this sequence of API calls. I've also updated this test to more explicitly check for a possible cause of customer issue b/332850329.

Same thing here. Can I get some clarity on what we are doing and looking for?

Added some explanation here as well as above in themake_connection() call.

Is there are reason we are using such a specific number?
1.125.

Can I get a comment here to let future me know why we picked this number?

IsmaxResults of0 synonymous with asking for all results? OR is it really asking for zero results?

We actually want 0 rows. If we omit this or ask for non-zero number of rows, thejobs.getQueryResults API can hang when the query has wide rows (many columns).