@tswast The PollingFuture 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 the DEFAULT_RETRY it uses).

I had actually planned to update the PollingFuture.result method to take the optional retry 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 the retry argument from _AsyncJob.result(), because of issues related to _OperationNotComplete.

If we close this PR without merging (i.e., we decide not to add a retry argument to _AsyncJob.result), then we should change _AsyncJob.result to pass through self._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 optional retry argument. It makes sense to me that we plumb that through so that callers of result can override the default.

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

from google.cloud.bigquery import job

...
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.