-
Notifications
You must be signed in to change notification settings - Fork 70
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
WhaleBasedAccountManager with Retry Mechanism #278
Conversation
It looks like the coordinator tests are failing now, please have a look and adjust accordingly. see: https://github.com/Consensys/linea-monorepo/actions/runs/11687214785/job/32693999670?pr=278 |
…oordination-ci-whale
…a-monorepo into fix/coordination-ci-whale
I've added a fix in this commit. Please note that I haven’t yet been able to run the coordinator tests locally. I’ve raised an issue regarding this setup difficulty here. |
@nadeemb53 The coordinator test is failed again and should be easily fixed by replacing |
result.forEach { (account, transferTx) -> | ||
|
||
result.forEach { pair -> | ||
val (account, transferTx) = pair |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this can be simplified as:
result.forEach { (account, transferTx) ->
@nadeemb53 FYI, we have a class called AsyncRetryer which could potentially be used for this case, the caveat is that it assumes the action return type is async and needs to pass in an vertx instance. |
Hi @nadeemb53 my apologies for the conflicts, I was not aware of this PR so in one of my PRs I fixed the issue because it was breaking the CI on my PR. The issue was that when we ran all tests in parallel (can be even different JVM processes), some tests may randomly be assigned the same whale account: Imagine that we have 4 tests sharing the whale account, and they send 4 competing transactions with the same nonce, 3 of them will get an error. These 3 remaining tests just need to retry sending the same transaction with a new nonce until it succeeds (the least lucky one will retry 3 times). Although the proposed solution would work just fine, the current solution with a simple retry works just fine, no need for extra logic for transaction replacement with gasPrice increase. Since the problem seems to be solved I think we can close this PR? |
makes sense, i'll close this |
This PR closes #215, which reported intermittent failures in the coordinator's integration tests due to nonce-related and gas price errors. The errors included "Replacement transaction underpriced" and "Nonce too low," originating from the WhaleBasedAccountManager
Checklist
Note: Changes are not tested