The fetchCredentials method uses only the default Retry method.

[lukas9393]

Hi, during a robustness check of our application, I discovered connection failures, like cURL error 35: OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to .... The application should try to connect again, so I have added a retry function to the BigQueryClient, which covers this case.

However, the application terminates with the error message mentioned above. During the investigation, I discovered that the connection attempt of the actual request was not aborted, but an additional request during the authentication process.

private function fetchCredentials(FetchAuthTokenInterface $credentialsFetcher)
    {
        $backoff = new ExponentialBackoff($this->retries, $this->getRetryFunction());

        try {
            return $backoff->execute(
                [$credentialsFetcher, 'fetchAuthToken'],
                [$this->authHttpHandler]
            );
        } catch (\Exception $ex) {
            throw $this->convertToGoogleException($ex);
        }
    }

RequestWrapper.php::[send:203->applyHeaders:293->fetchCredentials:318]

The method fetchCredentials uses only the internal retry method getRetryFunction. The ExponentialBackoff does not use the retry method passed to the client, nor does it use the retry method passed to the method by $option.

I would like to ask with this issue if this is intended or if I have overlooked a configuration how this method fetchCredentials can tolerate connection error. It could be that the person who implemented the function of custom retry methods forgot to provide it for method fetchCredentials.

private function fetchCredentials(FetchAuthTokenInterface $credentialsFetcher, array $options = [])
    {
        $retryOptions = $this->getRetryOptions($options);
        $backoff = new ExponentialBackoff(
            $retryOptions['retries'],
            $retryOptions['retryFunction']
        );

        if ($retryOptions['delayFunction']) {
            $backoff->setDelayFunction($retryOptions['delayFunction']);
        }

        if ($retryOptions['calcDelayFunction']) {
            $backoff->setCalcDelayFunction($retryOptions['calcDelayFunction']);
        }

        try {
            return $backoff->execute(
                [$credentialsFetcher, 'fetchAuthToken'],
                [$this->authHttpHandler]
            );
        } catch (\Exception $ex) {
            throw $this->convertToGoogleException($ex);
        }
    }

[georaldc]

Noticed this as well as I was trying to debug an issue where we would get really intermittent "invalid_grant" Bad Requests while the client attempts to fetch an auth token and was hoping if I could use a custom retry handler to include 400 http statuses.

[saranshdhingra]

Sorry that it's been long that this issue was posted and hasn't received any attention so far.

We're planning to to consolidate the retry layers between the auto generated and handwritten clients(BigQuery for example), so this issue will be eliminated soon.

This is just an FYI as there has not been any update on this issue from our side. Regards,

[saranshdhingra]

With the release of google/cloud-pubsub v2 last week, the package uses GAX's retry layer. This means that you can use all the options present in the RetrySettings namespace.

We are expecting a few other handwritten clients(not Storage and BigQuery yet) to move this way within the next month or so. I am not sure which product you were using to test, but we are definitely aiming to unite the auto generated and handwritten clients, so the use of RequestWrapper will slowly eliminate.

Closing this issue, for now, but if you want to keep the discussion open, please feel free to reopen this.

Thanks for your patience on this.

[lukas9393]

Thank you for the reply and the work to unify the clients with the correct RetrySettings. I am no longer working on this product but I will let the team know about this change.