Thanks for stopping by to let us know something could be better!
PLEASE READ: If you have a support contract with Google, please create an issue in the support console instead of filing on GitHub. This will ensure a timely response.
Is your feature request related to a problem? Please describe.
Regarding RunTransactionAsync on the FirestoreDb class in the Google.Cloud.Firestore package.
When we call it with MaxAttempts > 1 option, then we would like to have some sort of backoff policy, in our case for data contention, so that it does not spam the document when it is already in contention.
(note there is a backoff variable that is unused in the source code, not really relevant to the solution proposed below though)
Describe the solution you'd like
Either a backoff policy similar to what we see in the _batchGetCallSettings field or being able to pass an optional backoff policy to the method / client.
There's the issue of backwards compatibility, so maybe it does need to configurable by the user, defaulting to current behavior (no backoff).
Describe alternatives you've considered
Currently we're implementing our own backoff policy, wrapping around the firestoredb, but since you already have a backoff concept, it seemed reasonable to add it here as well.
Additional context
I admit that I'm a bit unsure if there's some internal backoff policy inside the lower internal functions that I haven't been able to divine, but from what I could see there's nothing obvious going on, so please correct me if there's anything I've misunderstood.
Thanks for stopping by to let us know something could be better!
PLEASE READ: If you have a support contract with Google, please create an issue in the support console instead of filing on GitHub. This will ensure a timely response.
Is your feature request related to a problem? Please describe.
Regarding RunTransactionAsync on the FirestoreDb class in the Google.Cloud.Firestore package.
When we call it with
MaxAttempts > 1option, then we would like to have some sort of backoff policy, in our case for data contention, so that it does not spam the document when it is already in contention.(note there is a
backoffvariable that is unused in the source code, not really relevant to the solution proposed below though)Describe the solution you'd like
Either a backoff policy similar to what we see in the
_batchGetCallSettingsfield or being able to pass an optional backoff policy to the method / client.There's the issue of backwards compatibility, so maybe it does need to configurable by the user, defaulting to current behavior (no backoff).
Describe alternatives you've considered
Currently we're implementing our own backoff policy, wrapping around the firestoredb, but since you already have a backoff concept, it seemed reasonable to add it here as well.
Additional context
I admit that I'm a bit unsure if there's some internal backoff policy inside the lower internal functions that I haven't been able to divine, but from what I could see there's nothing obvious going on, so please correct me if there's anything I've misunderstood.