feat: Implement retry mechanism for transient API failures - #18
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR adds a bounded retry helper with exponential backoff for transient transport/API failures and integrates it into the legacy and REST transports, with a small extension to APIError to mark errors as retryable.
Changes:
- Introduces
mytnb.client.retry.with_retry()plusRETRYABLE_STATUS_CODESand defaults for attempts/delay. - Extends
APIErrorwith aretryableflag and uses it to drive retry decisions. - Wraps legacy and REST transport requests with the retry helper and adds/extends tests for retry behavior.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
src/mytnb/client/retry.py |
New retry helper with exponential backoff + retryability rules. |
src/mytnb/exceptions.py |
Adds retryable flag to APIError to support retry signaling. |
src/mytnb/client/legacy.py |
Wraps legacy ASMX calls with with_retry and marks transient HTTP statuses retryable. |
src/mytnb/client/rest.py |
Wraps REST GET/POST with with_retry and converts retryable statuses into retryable APIError. |
tests/test_retry.py |
New unit tests validating retry helper behavior and constants. |
tests/test_client.py |
Adds legacy-transport retry tests and imports retry defaults. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces a robust retry mechanism for transient API and network errors in both the legacy and REST clients, improving reliability when communicating with the myTNB APIs. The main changes include a new
with_retryhelper with exponential backoff, integration of this helper into client methods, and comprehensive tests to ensure correct retry behavior.Retry mechanism implementation:
retry.pyimplementingwith_retry, a bounded retry helper with exponential backoff for transient HTTP status codes (e.g., 404, 5xx) and network errors, and definedRETRYABLE_STATUS_CODES.APIErrorexception to include aretryableflag, allowing errors to signal if they should be retried.Integration into client code:
legacy.pyandrest.pyclients to wrap API calls withwith_retry, raising retryableAPIErroron transient status codes and ensuring only safe errors are retried. [1] [2] [3] [4] [5] [6] [7]Testing and validation:
test_retry.pyto verify the retry logic, including correct handling of retryable and non-retryable errors and network exceptions.test_client.pywith tests for legacy client retry behavior on transient and persistent 404 errors, and adjusted imports for the new retry constants. [1] [2]These changes collectively improve the resilience of the client against intermittent backend failures, ensuring transient issues do not unnecessarily surface as hard errors to the caller.