Spanner: Python client not backing off on retries when RetryInfo not present.

[crwilcox]

When a session aborts, but doesn't have retry info python immediately retries. It seems to lack any sort of backoff here which may be incorrect. node attempts to.

https://github.com/googleapis/nodejs-spanner/blob/79f7855b3f6df59afe322dd578ed65f408a2fc2b/src/transaction.ts#L836

Python implementation currently returning 'None' if nothing is found:

google-cloud-python/spanner/google/cloud/spanner_v1/session.py

Line 353 in 92465cb

def _get_retry_delay(cause):

Go: https://github.com/googleapis/google-cloud-go/blob/ab1512ccf757de1b7f7f62883d9f975dfc152cef/spanner/internal/backoff/backoff.go#L43

[tseaver]

IIRC, this was the behavior specified by the spanner team (retry immediately if no trailing headers specify a perior).

[snehashah16]

When a session aborts, but doesn't have retry info python immediately retries. It seems to lack any sort of backoff here which may be incorrect. node attempts to.

Do you mean a Transaction aborts ?

For java, we use a default value to backoff & then retry if retryDelay is not specified in the response:
https://github.com/googleapis/google-cloud-java/blob/master/google-cloud-clients/google-cloud-spanner/src/main/java/com/google/cloud/spanner/SpannerImpl.java#L2681-L2705

The current values are:
MIN_BACKOFF_MS = 1000;
MAX_BACKOFF_MS = 32000;

private static ExponentialBackOff newBackOff() {
return new ExponentialBackOff.Builder()
.setInitialIntervalMillis(MIN_BACKOFF_MS)
.setMaxIntervalMillis(MAX_BACKOFF_MS)
.setMaxElapsedTimeMillis(Integer.MAX_VALUE) // Prevent Backoff.STOP from getting returned.
.build();

Since I don't recollect any other context, I would default to the behavior of the Java Client lib.

[snehashah16]

Lets verify this behavior across each of our libraries and fix as needed.

[tseaver]

@crwilcox I presume that removing the 'type: question' label and adding a priority means you want this to have 'type: bug'.

[IlyaFaer]

I've been working on that issue, and got a question. Several times I saw lines like that, and I can't imagine, what is second addend for? First one (with pow) is ok, increments delay time, but the second one (with random) doesn't grow. So after 2 tries it become disproportionately small part of whole delay time and, as I see it, useless

[crwilcox]

@IlyaFaer the random portion is to cause jitter in when we make requests and it shouldn't grow.

[tseaver]

Via #8461.