-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limit Requeues/Retries #26
Merged
Merged
Conversation
This file contains 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
…TransactionFaulted for unrecoverable/don't bother retrying errors, return updated params for an updated retry, or None if the strategy has no recommendation for updated params and the params should remain unchanged in which case wait for the existing tx a little while longer. There is no need to raise a Wait exception, since other strategies may feel differently.
…rn None if the machine should do nothing and wait based on this strategy. Remove Wait exception and its uses.
Ensure that even if some txs don't include both maxPriorityFeePerGas and maxFeePerGas the strategy still works. Handle legacy transaction speed up. Parameterize speed up factor and max tip. Questions remain about the default for max tip, but since parameterized, less of an issue - but something to revisit.
…ggested tip as a way to limit the speedup strategy getting out of control. Update maxFeePerGas depending on whether previously set or not - web3 py uses a default that doubles the base fee as part of maxFeePerGas so we probably don't want to further double that again. Clean up constructor params validation and update tests.
Use tx.id in addition to nonce for speed up logs.
…resent in transaction parameters (eip1559 allows one or both).
…re expontential because they build on previous updates.
…meout is too short and warn threshold becomes too low. Loosen warn factor from 5% to 15%.
…lling _cycle() on the machine - the latter could hide bugs so don't do it.
Don't have FutureTx store "from" separately from the the value in the params; it is redundant and complicates usage.
…ited to send raw transaction and returning the tx hash. Update machine and strategies use "from" value in the tx params. Make some functions void since unnecessary to return anything.
…eady been mined and needs replacing.
…can happen during broadcast or retry. Broadcast failures are handled differently than retry failures so added a new callback. InsufficientFunds is raised separately - but not currently handed; punting this decision to a different issue/pr.
…ansaction. Insufficient funds is a special case.
…t a subclass. It is also not needed as a extra strategy (at least for now), since it is encountered during firing to txs. It may/may not be considered a fault so left the Fault.INSUFFICIENT_FUNDS enum for now. More to be explored in a future issue/PR.
… Basically retries only happen after a broadcast has been successful, so we know that the base parameters were correct/fine. If we retry a tx with updated params and a failure occurs, the original broadcasted tx was still broadcasted so don't fault immediately; instead skip the round. However, at some point we have to decide whether or not to keep waiting for the original broadcasted tx. It is somewehat analogous to how many requeues we allow for a failed broadcast of a tx. Both can be explored as part of nucypher#12, nucypher#14.
…during broadcast.
… strategies to retry a tx.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #26 +/- ##
=======================================
Coverage ? 94.13%
=======================================
Files ? 14
Lines ? 1654
Branches ? 0
=======================================
Hits ? 1557
Misses ? 97
Partials ? 0 ☔ View full report in Codecov by Sentry. |
…. This allows for not needing extra logic for clearing out the dictionary used in the original tracking logic. Instead requeues and retries can be tracked on the tx object itself. Requeues for FutureTx can easily be incremented via the requeue() call on the tracker.It's a little trickier with PendingTx since we only deal with copies in the machine, but added a method to the tracker to make this easier. Updated tests.
Merged
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.
Based over #25 .
Fixes #12 .
Going the limit requeues/retries based on number of attempts route for now.