@tswast ThePollingFuture base class already stores a retry object. If we assigned to it, we would need to ensure that its predicate included the test for_OperationNotComplete (see theDEFAULT_RETRY it uses).

I had actually planned to update thePollingFuture.result method to take the optionalretry argument as well, but wanted to think about how to deal with the_OperationNotComplete bit first.

@tswast Please see#6305 for the changes to retry the polling requests. I haven't piped through theretry argument from_AsyncJob.result(), because of issues related to_OperationNotComplete.

If we close this PR without merging (i.e., we decidenot to add aretry argument to_AsyncJob.result), then we should change_AsyncJob.result to pass throughself._retry to the_begin call. That change won't really be useful until#6305 lands, however.

@tseaver is this needed at all if we do#6305?

@crwilcox

is this needed at all if we do#6305?

Depends The_AsyncJob.result method itself can invoke_begin, which takes an optionalretry argument. It makes sense to me that we plumb that through so that callers ofresult can override the default.

If we decidenot to expose it, then I think westill need to pass theself._retry attribute through to begin, because the application might've configured it to override e.g., the timeout from the defaults, via something like:

fromgoogle.cloud.bigqueryimportjob...copy_job=job.CopyJob(job_ref,sources,destination,client=client,job_config=job_config)copy_job._retry=copy_job._retry.with_deadline(600)result=copy_job.result()

Rebased to work around borked CI runs for irrelevant APIs.