Retry after retryable error codes

[dmachehin]

Maybe have "use case" for automatic retries globally (all methods) for error codes LIKE CONCURRENT_MODIFICATION ?

[PierrickVoulet]

@dmachehin This is not a feature that we currently provide. Thank you for the suggestion!

[dacog]

@PierrickVoulet @fiboknacky Such a feature would be great!

Is such a feature already there? Or is it in the Roadmap?

I see the issue is still open, with a difficulty:hard label.

Maybe documenting a working workaround would be good?

A workaround is to check the message content for "Retry the request", but there are other errors that don't have a retry in the message, such as when a resource is not yet available (for example, when creating a Google Ads account and assigning a Billing profile to it). In those cases, I become a Request contains an invalid argument error because of BILLING_SETUP_IN_PROGRESS. If I wait around 5-10 min, the ID works.

This workaround depends on the structure of the error message being always the same and always indicating if one should retry the request, which in my experience it doesn't.

Here is a small snippet for the retry.

private function isRetryRequestInErrorMessage(Exception $exception): bool
    {
        return ($exception::class === GoogleAdsException::class || $exception::class === ApiException::class) &&
            str_contains($exception->getBasicMessage(), 'Retry the request') ||
            str_contains($exception->getMessage(), 'Retry the request');
    }

That snippet does not cover the invalid argument error because not in every case you should retry (such as when the argument, such as a resource name, really does not exist).

Are there any best practices for such retries that I haven't found yet?

Thanks!

Diego

[fiboknacky]

I'm sorry that this was off my radar.
Thanks so much for sharing your thoughts. We still keep this feature request for now, but frankly speaking, I don't have bandwidth to work on this soon.

About what you suggest, it totally makes sense, although we might need to be careful about the error message since it can be easily changed, unlike the enum values themselves.
When I have more time, I'll take a look at this more deeply and will consider adding this to our documentation.