-
Notifications
You must be signed in to change notification settings - Fork 626
fix(gas-oracle): nonce too low when resubmission #1712
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
Conversation
WalkthroughThis change updates the version tag to "v4.5.36" and improves nonce initialization by considering both database and client pending nonces. It adds handling for "nonce too low" errors during transaction resubmission by marking the original and replacement transactions as failed. Additionally, it introduces a method to retrieve the maximum nonce by sender address from the database and adds a test for this method. Changes
Sequence Diagram(s)sequenceDiagram
participant Sender
participant ORM
participant DB
Sender->>ORM: GetMaxNonceBySenderAddress(sender)
ORM->>DB: Query max nonce for sender
DB-->>ORM: Return max nonce
ORM-->>Sender: Return max nonce
Sender->>Sender: initializeNonce() = max(DB max nonce + 1, client pending nonce)
Sender->>Sender: Log nonce initialization/reset
Sender->>Sender: SendTransaction()
alt Error contains "nonce too low"
Sender->>Sender: resetNonce()
Sender->>Sender: Log nonce reset
Sender->>Sender: Return error if reset fails
end
Sender->>Sender: checkPendingTransaction()
alt Resubmission "nonce too low" error
Sender->>Sender: Log warning
Sender->>DB: Update original and replacement tx status to ConfirmedFailed
Sender-->>Sender: Return early (no rollback)
else Other errors
Sender->>Sender: Existing rollback/error handling
end
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #1712 +/- ##
===========================================
+ Coverage 39.55% 39.65% +0.09%
===========================================
Files 237 237
Lines 18999 19033 +34
===========================================
+ Hits 7516 7547 +31
+ Misses 10743 10742 -1
- Partials 740 744 +4
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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.
Actionable comments posted: 0
🧹 Nitpick comments (1)
rollup/internal/orm/orm_test.go (1)
601-657: Well-structured test with good coverage of basic scenarios.The test properly covers both the empty state (no transactions) and populated state (multiple transactions with different nonces). The test setup is clean and follows established patterns in the file.
Consider adding these test cases for more comprehensive coverage:
- Multiple transactions with the same nonce for the same sender
- Transactions for different sender addresses to verify proper filtering
- Testing with nonce 0 to ensure it's handled correctly
Example of additional test cases:
+ // Test with different sender address to ensure proper filtering + differentSender := &SenderMeta{ + Name: "differentSender", + Service: "testService", + Address: common.HexToAddress("0xbeefcafe"), + Type: types.SenderTypeCommitBatch, + } + tx2 := gethTypes.NewTx(&gethTypes.DynamicFeeTx{ + Nonce: 5, + To: &common.Address{}, + Data: []byte{}, + Gas: 23000, + AccessList: gethTypes.AccessList{}, + Value: big.NewInt(0), + ChainID: big.NewInt(1), + GasTipCap: big.NewInt(2), + GasFeeCap: big.NewInt(3), + V: big.NewInt(0), + R: big.NewInt(0), + S: big.NewInt(0), + }) + err = pendingTransactionOrm.InsertPendingTransaction(context.Background(), "test", differentSender, tx2, 0) + assert.NoError(t, err) + + // Original sender should still have max nonce 3 + maxNonce, err = pendingTransactionOrm.GetMaxNonceBySenderAddress(context.Background(), senderMeta.Address.String()) + assert.NoError(t, err) + assert.Equal(t, uint64(3), maxNonce) + + // Different sender should have max nonce 5 + maxNonce, err = pendingTransactionOrm.GetMaxNonceBySenderAddress(context.Background(), differentSender.Address.String()) + assert.NoError(t, err) + assert.Equal(t, uint64(5), maxNonce)
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
rollup/internal/orm/orm_test.go(1 hunks)rollup/internal/orm/pending_transaction.go(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- rollup/internal/orm/pending_transaction.go
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: tests
- GitHub Check: tests
- GitHub Check: check
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.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
rollup/internal/controller/sender/sender.go(6 hunks)rollup/internal/orm/orm_test.go(1 hunks)rollup/internal/orm/pending_transaction.go(2 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- rollup/internal/orm/orm_test.go
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: tests
- GitHub Check: check
- GitHub Check: tests
🔇 Additional comments (6)
rollup/internal/orm/pending_transaction.go (2)
6-6: LGTM!The
database/sqlimport is correctly added to support thesql.NullInt64type used in the newGetMaxNonceBySenderAddressmethod.
212-232: LGTM!The
GetMaxNonceBySenderAddressmethod is well-implemented with proper error handling and null value management. The use ofsql.NullInt64correctly handles the case where no transactions exist for the given address, and returning -1 is appropriately documented and consistent with its usage in the sender logic.rollup/internal/controller/sender/sender.go (4)
108-134: LGTM!The constructor changes improve nonce initialization by using the
resetNonce()method, which now considers both database and client nonces through the newinitializeNonce()method. The error handling is appropriate and the approach consolidates nonce initialization logic.
332-360: LGTM!The
initializeNoncemethod implements robust nonce initialization logic by considering both database and client states. The approach of taking the maximum between pending nonce and (db nonce + 1) ensures consistency, and the comprehensive logging aids in debugging. The error handling is appropriate with descriptive messages.
363-372: LGTM!The
resetNoncemethod improvements are excellent. The method now returns an error for proper error propagation and uses the newinitializeNoncemethod for consistency. This addresses the past review comment about applying the "maximum of both values" logic to theresetNoncefunction as well.
244-247: LGTM!The error handling for the
resetNonce()call is appropriate since the method signature now returns an error. The early return on failure and descriptive error messaging maintain consistency with the existing error handling patterns in this method.
Purpose or design rationale of this PR
When resubmission receives "nonce too low" error, it means the transaction has already been mined. In such cases sender can skip resubmitting such transactions.
This PR also adds another robustness fix about initializing/resetting nonce by setting it as
max(pending nonce from the nonce, max db's nonce + 1).PR title
Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:
Deployment tag versioning
Has
tagincommon/version.gobeen updated or have you addedbump-versionlabel to this PR?Breaking change label
Does this PR have the
breaking-changelabel?Summary by CodeRabbit
Summary by CodeRabbit
Bug Fixes
New Features
Chores