-
Notifications
You must be signed in to change notification settings - Fork 22
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
Simplify adapters #321
Simplify adapters #321
Conversation
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 golangci-lint (1.62.2)level=warning msg="The linter 'exportloopref' is deprecated (since v1.60.2) due to: Since Go1.22 (loopvar) this linter is no longer relevant. Replaced by copyloopvar." WalkthroughThe pull request introduces significant modifications to transaction adaptation logic in the Changes
Suggested reviewers
Possibly related PRs
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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 (
|
2456b4c
to
505bfa9
Compare
This is purely a refactor. All behavior should remain exactly the same. |
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
🧹 Nitpick comments (1)
adapters.go (1)
25-30
: Clarify error message when first transaction is not an L1 attributes deposit transactionAt line 29, the error message could be more specific to indicate that the expected first transaction is the L1 attributes deposit transaction. Improving the error message will aid in debugging and understanding the code flow.
Consider updating the error message:
- return nil, errors.New("first transaction is not a deposit transaction") + return nil, errors.New("first transaction is not the L1 attributes deposit transaction")
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
adapters.go
(3 hunks)
🔇 Additional comments (2)
adapters.go (2)
89-91
: Inconsistent handling of deposit transactions after non-deposit transactions
In lines 89-91, if a deposit transaction is found after processing non-deposit transactions, an error is returned. This could halt processing valid transactions if deposit transactions are unordered.
Please verify that deposit transactions cannot occur after non-deposit transactions in ethTxs
. If this is a possibility, consider adjusting the code to handle such cases gracefully.
117-131
: Ensure correct reassembly of Ethereum transactions from Cosmos transactions
The code from lines 117 to 131 correctly reconstructs Ethereum transactions from Cosmos transactions, including L1 attributes and user deposits. The implementation appears correct and follows the expected logic.
for _, ethDepositTxBytes := range ethTxs { | ||
var ethDepositTx ethtypes.Transaction | ||
if err := ethDepositTx.UnmarshalBinary(ethDepositTxBytes); err != nil { | ||
return nil, fmt.Errorf("unmarshal binary eth deposit tx bytes: %v", err) | ||
} | ||
if !ethDepositTx.IsDepositTx() { | ||
break // We have reached the end of the deposit txs. | ||
} | ||
depositTxs = append(depositTxs, &rolluptypes.MsgApplyUserDeposit{ | ||
Tx: ethDepositTxBytes, | ||
}) | ||
} | ||
return &rolluptypes.DepositsTx{ | ||
ethTxs = ethTxs[len(depositTxs):] |
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.
🛠️ Refactor suggestion
Ensure all deposit transactions are processed regardless of order
The loop from lines 58 to 69 processes deposit transactions until it encounters a non-deposit transaction, then breaks. If there are deposit transactions after non-deposit transactions in ethTxs
, they will not be processed, potentially leading to missed deposits.
Consider processing all transactions and separating deposit and non-deposit transactions regardless of order. Here's how you might modify the code:
depositTxs := []*rolluptypes.MsgApplyUserDeposit{}
nonDepositTxs := []hexutil.Bytes{}
for _, ethTxBytes := range ethTxs {
var ethTx ethtypes.Transaction
if err := ethTx.UnmarshalBinary(ethTxBytes); err != nil {
return nil, fmt.Errorf("unmarshal binary eth tx bytes: %v", err)
}
if ethTx.IsDepositTx() {
depositTxs = append(depositTxs, &rolluptypes.MsgApplyUserDeposit{
Tx: ethTxBytes,
})
} else {
nonDepositTxs = append(nonDepositTxs, ethTxBytes)
}
}
ethTxs = nonDepositTxs
This ensures that all deposit transactions are processed regardless of their position in ethTxs
.
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.
LGTM
Summary by CodeRabbit
New Features
Bug Fixes
Documentation