| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
| Retry a specified function with different logic based on the type of exception raised. | ||
|
|
||
| If the exception is of type google.api_core.exceptions.Aborted, | ||
| apply an alternate retry strategy that relies on the provided deadline value instead of a fixed number of retries. | ||
| For all other exceptions, retry the function up to a specified number of times. |
There was a problem hiding this comment.
This API is not really logical. I would suggest splitting this into two separate functions:
In the current form, the API is quite 'magical' and hard to understand. What is for example the definition of this function if you call it with Aborted as one of the allowed exceptions? Will it use the specific logic for Aborted in all cases? Or only if you have also supplied a deadline? What is the meaning of retry_count if you use to it retry Aborted errors? etc...
Sorry, something went wrong.
There was a problem hiding this comment.
If the exception is of type Aborted, it will activate the custom retry strategy. However, this will only occur if the user has listed this exception in the allowed_exceptions map and provided a deadline value. If either condition is missing, the exception will not be retried. For the batch API use case, we will specifically allow this exception to be retried.
Sorry, something went wrong.
There was a problem hiding this comment.
I meant that the _retry function and the _retry_on_aborted_exception should be completely separated. I don't really see any advantage of combining them, as the actual code that can be shared is minimal, and the API surface of this function is not logical.
E.g. if you have defined Aborted as a retryable exception, but you forget to supply a deadline, then all of a sudden it is not retriable. Also, deadline is only used if you add Aborted as a possible retryable error, and is otherwise ignored if you only supply other error codes. Same with retry_count; it is only used for non-Aborted errors. The fact that there are many combinations of input arguments that don't make any sense, is an indication that the function itself should be split.
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks for the clarification. I've implemented the new retry logic as suggested, separating the _retry and _retry_on_aborted_exception functions. This ensures clearer logic, as combining them led to confusing combinations of parameters that didn't make sense. Now, the retry logic for non-Aborted and Aborted exceptions is more distinct and easier to manage.
Sorry, something went wrong.
| while retries <= retry_count: | ||
| while True: |
There was a problem hiding this comment.
This breaks existing use cases that rely on this function to stop retrying after N retries.
Sorry, something went wrong.
There was a problem hiding this comment.
I believe the check for retries < retry_count is already in place for generic retries. This ensures that the while loop terminates early and an exception is raised once the retry count is exceeded. So, in my opinion, this logic should work correctly for generic retries as well.
Sorry, something went wrong.
| return MutationGroup(self._session, mutation_group.mutations) | ||
|
|
||
| def batch_write(self, request_options=None, exclude_txn_from_change_streams=False): | ||
| def batch_write( |
There was a problem hiding this comment.
batch_write is a bit different. I don't think we should include it in this PR, as it is a non-atomic, streaming operation, that probably needs different error handling than 'just retry if it fails with an aborted error'.
Sorry, something went wrong.
There was a problem hiding this comment.
Understood. In that case, we can bypass the retry behavior for this operation.
Sorry, something went wrong.
There was a problem hiding this comment.
Please also remove the **kwargs addition again from this PR. It would just be confusing if that is added in this PR, when it is not relevant to the actual change in this PR.
Sorry, something went wrong.
| def no_op_handler(exc): | ||
| # No-op (does nothing) | ||
| pass |
There was a problem hiding this comment.
Can we remove this and just pass in a lambda where a no-op handler is needed (if it is needed at all after we separate the normal retry function from the aborted retry function)?
Sorry, something went wrong.
There was a problem hiding this comment.
Yes, we can use a no-op lambda for this.
Sorry, something went wrong.
There was a problem hiding this comment.
Removed the redundant code as this is no longer required with the new implementation.
Sorry, something went wrong.
| def session_id(self): | ||
| return self.name | ||
|
|
||
| def run_in_transaction(self, fnc): |
There was a problem hiding this comment.
Why is this here? It does not look like a test method.
Sorry, something went wrong.
There was a problem hiding this comment.
Yes, it's not needed here. This change is carried forward from my previous PR where we call the run_in_transaction method instead.
Sorry, something went wrong.
There was a problem hiding this comment.
Removed in subsequent commits.
Sorry, something went wrong.
| raise | ||
|
|
||
| delay = _get_retry_delay(cause, attempts) | ||
| print(now, delay, deadline) |
There was a problem hiding this comment.
nit: remove
Sorry, something went wrong.
There was a problem hiding this comment.
I extracted these methods to make them more generic, allowing other clients to reuse the logic instead of it being tightly coupled with the session object.
Sorry, something went wrong.
There was a problem hiding this comment.
I meant: Remove the print(...) line. We should not print debug info in non-test code (and normally also not in test code).
Sorry, something went wrong.
There was a problem hiding this comment.
Noted. Removed from subsequent commits.
Sorry, something went wrong.
googleapis#1281) Source-Link: googleapis/synthtool@de3def6 Post-Processor: gcr.io/cloud-devrel-public-resources/owlbot-python:latest@sha256:a1c5112b81d645f5bbc4d4bbc99d7dcb5089a52216c0e3fb1203a0eeabadd7d5 Co-authored-by: Owl Bot <gcf-owl-bot[bot]@users.noreply.github.com>
…an up redundant code
| def _retry_on_aborted_exception( | ||
| func, | ||
| deadline, | ||
| allowed_exceptions=None, |
There was a problem hiding this comment.
I think that we can simplify this further and just remove allowed_exceptions from this function. It should only retry aborted exceptions.
Sorry, something went wrong.
| except Exception as exc: | ||
| try: | ||
| retry_result = _retry(func=func, allowed_exceptions=allowed_exceptions) | ||
| if retry_result is not None: | ||
| return retry_result | ||
| else: | ||
| raise exc | ||
| except Aborted: | ||
| continue |
There was a problem hiding this comment.
I think that we should remove this part entirely. I know that the previous implementation of Batch retried this specific RST_STREAM error, but that was just a copy-paste from other methods. That error is not relevant for this type of operation.
Sorry, something went wrong.
| Args: | ||
| func: The function to be retried. | ||
| retry_count: The maximum number of times to retry the function. | ||
| deadline: This will be used in case of Aborted transactions. |
There was a problem hiding this comment.
nit: remove, this is not relevant anymore
Sorry, something went wrong.
| return MutationGroup(self._session, mutation_group.mutations) | ||
|
|
||
| def batch_write(self, request_options=None, exclude_txn_from_change_streams=False): | ||
| def batch_write( |
There was a problem hiding this comment.
Please also remove the **kwargs addition again from this PR. It would just be confusing if that is added in this PR, when it is not relevant to the actual change in this PR.
Sorry, something went wrong.
Recognize GRAPH and pipe syntax queries as valid queries in dbapi.
…leapis#1273) * chore: Add Custom OpenTelemetry Exporter in for Service Metrics * Updated copyright dates to 2025 --------- Co-authored-by: rahul2393 <irahul@google.com>
…d_exception handler
| Back | FazBrowse Home | New Git URL |
Updating retry strategy for mutation calls to handle aborted transactions
This PR updates the retry strategy for mutation calls to handle aborted transactions more effectively. Previously, the retry mechanism didn't handle certain edge cases for aborted transactions, leading to failures. The updated strategy ensures retries in these scenarios to improve the robustness of the mutation operations.
Test Results:
All unit tests related to the retry logic and mutation operations pass successfully.
Fixes #1133