test: add E2E testing for V2 contract migration #2763
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughWalkthroughThe changes encompass the introduction of new features and enhancements to existing functionalities across various components of the system. Key updates include the addition of migration testing parameters, user account configurations for version 2, enhancements to end-to-end testing routines, and improvements to contract management processes. The modifications facilitate better handling of version migrations, optimize balance checks, and refine error handling and logging mechanisms. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Workflow
participant Contract
participant Keeper
User->>Workflow: Trigger v2 Migration Test
Workflow->>Keeper: Set up migration parameters
Keeper->>Contract: Deploy new v2 contracts
Contract-->>Keeper: Confirm deployment
Keeper->>Keeper: Update gateway address
Keeper->>User: Migration test completed
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
Documentation and Community
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #2763 +/- ##
===========================================
- Coverage 66.65% 66.61% -0.04%
===========================================
Files 370 370
Lines 20680 20732 +52
===========================================
+ Hits 13784 13811 +27
- Misses 6261 6283 +22
- Partials 635 638 +3
|
There was a problem hiding this comment.
Actionable comments posted: 8
Outside diff range, codebase verification and nitpick comments (3)
cmd/zetae2e/local/post_tss_migration.go (1)
Line range hint
14-54: Enhance error handling and add logging.
- Enhance error handling to provide more context.
- Add logging for better traceability of the steps.
Apply this diff to improve the function:
func postTSSMigrationTestRoutine( conf config.Config, deployerRunner *runner.E2ERunner, verbose bool, testNames ...string, ) func() error { return func() (err error) { account := conf.AdditionalAccounts.UserBitcoin // initialize runner for post migration test + postMigrationRunner.Logger.Print("Initializing post migration runner") postMigrationRunner, err := initTestRunner( "postTSSMigration", conf, deployerRunner, account, runner.NewLogger(verbose, color.FgMagenta, "postTSSMigration"), ) if err != nil { - return err + return fmt.Errorf("failed to initialize post migration runner: %w", err) } postMigrationRunner.Logger.Print("🏃 starting post TSS migration tests") startTime := time.Now() testsToRun, err := postMigrationRunner.GetE2ETestsToRunByName( e2etests.AllE2ETests, testNames..., ) if err != nil { - return errors.Wrap(err, "post TSS migration tests failed") + return errors.Wrap(err, "failed to get E2E tests to run: %w", err) } if err := postMigrationRunner.RunE2ETests(testsToRun); err != nil { - return errors.Wrap(err, "post TSS migration tests failed") + return errors.Wrap(err, "failed to run E2E tests: %w", err) } if err := postMigrationRunner.CheckBtcTSSBalance(); err != nil { - return err + return fmt.Errorf("failed to check BTC TSS balance: %w", err) } postMigrationRunner.Logger.Print("🍾 post TSS migration tests completed in %s", time.Since(startTime).String()) return err } }cmd/zetae2e/local/tss_migration.go (1)
Line range hint
14-59: Enhance error handling and add logging.
- Enhance error handling to provide more context.
- Add logging for better traceability of the steps.
Apply this diff to improve the function:
func tssMigrationTestRoutine( conf config.Config, deployerRunner *runner.E2ERunner, verbose bool, testNames ...string, ) func() error { return func() (err error) { account := conf.AdditionalAccounts.UserMigration // initialize runner for migration test + tssMigrationTestRunner.Logger.Print("Initializing TSS migration runner") tssMigrationTestRunner, err := initTestRunner( "TSSmigration", conf, deployerRunner, account, runner.NewLogger(verbose, color.FgHiGreen, "migration"), runner.WithZetaTxServer(deployerRunner.ZetaTxServer), ) if err != nil { - return err + return fmt.Errorf("failed to initialize TSS migration runner: %w", err) } tssMigrationTestRunner.Logger.Print("🏃 starting TSS migration tests") startTime := time.Now() if len(testNames) == 0 { tssMigrationTestRunner.Logger.Print("🍾 TSS migration tests completed in %s", time.Since(startTime).String()) return nil } // run TSS migration test + tssMigrationTestRunner.Logger.Print("Running TSS migration tests") testsToRun, err := tssMigrationTestRunner.GetE2ETestsToRunByName( e2etests.AllE2ETests, testNames..., ) if err != nil { - return fmt.Errorf("TSS migration tests failed: %v", err) + return fmt.Errorf("failed to get E2E tests to run: %w", err) } if err := tssMigrationTestRunner.RunE2ETests(testsToRun); err != nil { - return fmt.Errorf("TSS migration tests failed: %v", err) + return fmt.Errorf("failed to run E2E tests: %w", err) } if err := tssMigrationTestRunner.CheckBtcTSSBalance(); err != nil { - return err + return fmt.Errorf("failed to check BTC TSS balance: %w", err) } tssMigrationTestRunner.Logger.Print("🍾 TSS migration tests completed in %s", time.Since(startTime).String()) return err } }e2e/runner/v2_migration.go (1)
52-68: Enhance Error Handling inupgradeZRC20sFunctionThe
upgradeZRC20sfunction currently lacks explicit error handling for theupgradeZRC20calls. While errors fromChainIDare checked, failures in upgrading ZRC20s should also be managed to ensure the process is robust and reliable. Consider adding error checks for eachupgradeZRC20call to handle potential issues effectively.
- File:
e2e/runner/v2_migration.go- Lines: 59, 63, 67
Analysis chain
Verify the correctness of each upgrade step in
upgradeZRC20s.The function
upgradeZRC20sincludes multiple steps for upgrading ZRC20s. Ensure that each step handles all possible error scenarios and edge cases.Run the following script to verify the function usage:
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all function calls to `upgradeZRC20s` match the expected usage. # Test: Search for the function usage. Expect: Only occurrences of the expected usage. rg --type go -A 5 $'upgradeZRC20s'Length of output: 743
Script:
#!/bin/bash # Extract the full implementation of the `upgradeZRC20s` function to verify error handling and edge case management. ast-grep --lang go --pattern $'func (r *E2ERunner) upgradeZRC20s() { $$$ }'Length of output: 1236
Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
Files selected for processing (26)
- .github/workflows/e2e.yml (7 hunks)
- Makefile (1 hunks)
- cmd/zetae2e/config/localnet.yml (1 hunks)
- cmd/zetae2e/local/local.go (9 hunks)
- cmd/zetae2e/local/post_tss_migration.go (2 hunks)
- cmd/zetae2e/local/tss_migration.go (3 hunks)
- cmd/zetae2e/local/v2.go (1 hunks)
- contrib/localnet/orchestrator/start-zetae2e.sh (1 hunks)
- contrib/localnet/scripts/start-zetacored.sh (1 hunks)
- e2e/config/config.go (3 hunks)
- e2e/e2etests/test_migrate_erc20_custody_funds.go (1 hunks)
- e2e/runner/accounting.go (1 hunks)
- e2e/runner/evm.go (2 hunks)
- e2e/runner/v2_migration.go (1 hunks)
- e2e/runner/v2_setup_evm.go (2 hunks)
- e2e/runner/v2_setup_zeta.go (2 hunks)
- e2e/txserver/authority.go (1 hunks)
- e2e/txserver/zeta_tx_server.go (1 hunks)
- go.mod (1 hunks)
- x/fungible/keeper/msg_server_update_gateway_contract.go (3 hunks)
- x/fungible/keeper/msg_server_update_gateway_contract_test.go (3 hunks)
- x/fungible/keeper/v2_evm.go (2 hunks)
- zetaclient/chains/bitcoin/observer/inbound.go (2 hunks)
- zetaclient/chains/bitcoin/observer/observer.go (2 hunks)
- zetaclient/chains/evm/signer/signer.go (1 hunks)
- zetaclient/orchestrator/orchestrator.go (3 hunks)
Files skipped from review due to trivial changes (2)
- e2e/e2etests/test_migrate_erc20_custody_funds.go
- e2e/txserver/zeta_tx_server.go
Additional context used
Path-based instructions (20)
e2e/txserver/authority.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.cmd/zetae2e/local/post_tss_migration.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.cmd/zetae2e/local/tss_migration.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.x/fungible/keeper/msg_server_update_gateway_contract.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/runner/v2_setup_zeta.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/runner/v2_setup_evm.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.cmd/zetae2e/local/v2.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.x/fungible/keeper/v2_evm.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.x/fungible/keeper/msg_server_update_gateway_contract_test.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/runner/accounting.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/runner/v2_migration.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.e2e/runner/evm.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.contrib/localnet/orchestrator/start-zetae2e.sh (1)
Pattern
**/*.sh: Review the shell scripts, point out issues relative to security, performance, and maintainability.e2e/config/config.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.zetaclient/chains/bitcoin/observer/inbound.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.contrib/localnet/scripts/start-zetacored.sh (1)
Pattern
**/*.sh: Review the shell scripts, point out issues relative to security, performance, and maintainability.cmd/zetae2e/local/local.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.zetaclient/chains/evm/signer/signer.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.zetaclient/chains/bitcoin/observer/observer.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.zetaclient/orchestrator/orchestrator.go (1)
Pattern
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
Gitleaks
cmd/zetae2e/config/localnet.yml
47-47: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
51-51: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
55-55: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
59-59: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
Additional comments not posted (57)
x/fungible/keeper/msg_server_update_gateway_contract.go (4)
8-9: LGTM!The new imports are necessary for the added functionality.
The code changes are approved.
26-34: LGTM!The parsing and validation of the new gateway address are correctly implemented.
The code changes are approved.
47-64: LGTM!The update of ZRC20 contracts with the new gateway address is correctly implemented, and the error handling enhances robustness.
The code changes are approved.
Line range hint
66-74: LGTM!The event emission and final steps are correctly implemented, enhancing the function's interactivity with other components of the system.
The code changes are approved.
e2e/runner/v2_setup_zeta.go (2)
78-80: LGTM!The updated comment and method name accurately describe the expanded functionality.
The code changes are approved.
104-106: LGTM!The expanded functionality enhances the method's capability to manage multiple contract addresses during transitions.
The code changes are approved.
e2e/runner/v2_setup_evm.go (2)
25-25: LGTM!The improved logging provides a more structured logging level, enhancing clarity.
The code changes are approved.
107-112: LGTM!The new functionality for setting legacy support enhances the method's capability to manage legacy support for deposits.
The code changes are approved.
cmd/zetae2e/local/v2.go (2)
15-71: Add error handling foreg.Gocalls.The function is well-structured and leverages concurrency for efficiency. However, it lacks error handling for the
eg.Gocalls, which could lead to unhandled errors. Consider adding error handling to ensure that any errors encountered during the execution of the test routines are properly managed.func startV2Tests(eg *errgroup.Group, conf config.Config, deployerRunner *runner.E2ERunner, verbose bool) { // Test happy paths for gas token workflow - eg.Go(v2TestRoutine(conf, "eth", conf.AdditionalAccounts.UserV2Ether, color.FgHiGreen, deployerRunner, verbose, + eg.Go(func() error { + return v2TestRoutine(conf, "eth", conf.AdditionalAccounts.UserV2Ether, color.FgHiGreen, deployerRunner, verbose, e2etests.TestV2ETHDepositName, e2etests.TestV2ETHDepositAndCallName, e2etests.TestV2ETHWithdrawName, e2etests.TestV2ETHWithdrawAndCallName, e2etests.TestV2ZEVMToEVMCallName, e2etests.TestV2EVMToZEVMCallName, - )) + ) + }) // Test happy paths for erc20 token workflow - eg.Go(v2TestRoutine(conf, "erc20", conf.AdditionalAccounts.UserV2ERC20, color.FgHiBlue, deployerRunner, verbose, + eg.Go(func() error { + return v2TestRoutine(conf, "erc20", conf.AdditionalAccounts.UserV2ERC20, color.FgHiBlue, deployerRunner, verbose, e2etests.TestV2ETHDepositName, // necessary to pay fees on ZEVM e2etests.TestV2ERC20DepositName, e2etests.TestV2ERC20DepositAndCallName, e2etests.TestV2ERC20WithdrawName, e2etests.TestV2ERC20WithdrawAndCallName, - )) + ) + }) // Test revert cases for gas token workflow eg.Go(func() error { return v2TestRoutine( conf, "eth-revert", conf.AdditionalAccounts.UserV2EtherRevert, color.FgHiYellow, deployerRunner, verbose, e2etests.TestV2ETHDepositName, // necessary to pay fees on ZEVM and withdraw e2etests.TestV2ETHDepositAndCallRevertName, e2etests.TestV2ETHDepositAndCallRevertWithCallName, e2etests.TestV2ETHWithdrawAndCallRevertName, e2etests.TestV2ETHWithdrawAndCallRevertWithCallName, ) }) // Test revert cases for erc20 token workflow eg.Go(func() error { return v2TestRoutine( conf, "erc20-revert", conf.AdditionalAccounts.UserV2ERC20Revert, color.FgHiRed, deployerRunner, verbose, e2etests.TestV2ETHDepositName, // necessary to pay fees on ZEVM e2etests.TestV2ERC20DepositName, // necessary to have assets to withdraw e2etests.TestOperationAddLiquidityETHName, // liquidity with gas and ERC20 are necessary for reverts e2etests.TestOperationAddLiquidityERC20Name, e2etests.TestV2ERC20DepositAndCallRevertName, e2etests.TestV2ERC20DepositAndCallRevertWithCallName, e2etests.TestV2ERC20WithdrawAndCallRevertName, e2etests.TestV2ERC20WithdrawAndCallRevertWithCallName, ) }) }
Line range hint
74-122: LGTM!The function is well-implemented and follows best practices. The TODO comment is a good indication of future improvements.
The code changes are approved.
x/fungible/keeper/v2_evm.go (2)
18-42: Add validation for the new gateway address.The function is well-implemented and follows best practices. However, there is no validation for the new gateway address. Consider adding a validation check to ensure that the new gateway address is not empty or invalid.
func (k Keeper) CallUpdateGatewayAddress( ctx sdk.Context, zrc20Address common.Address, newGatewayAddress common.Address, ) (*evmtypes.MsgEthereumTxResponse, error) { zrc20ABI, err := zrc20.ZRC20MetaData.GetAbi() if err != nil { return nil, err } + if crypto.IsEmptyAddress(newGatewayAddress) { + return nil, fmt.Errorf("new gateway address is empty or invalid") + } return k.CallEVM( ctx, *zrc20ABI, types.ModuleAddressEVM, zrc20Address, BigIntZero, nil, true, false, "updateGatewayAddress", newGatewayAddress, ) }
196-203: LGTM!The changes are minor and do not affect the logic or functionality of the code.
The code changes are approved.
x/fungible/keeper/msg_server_update_gateway_contract_test.go (5)
18-91: LGTM!The changes enhance the test by adding more comprehensive checks for the gateway contract address update in ZRC20 contracts.
The code changes are approved.
Line range hint
92-123: LGTM!The changes add a new test case to ensure that the gateway contract can be updated and overwritten if the system contract state variable is not found.
The code changes are approved.
Line range hint
124-153: LGTM!The changes add a new test case to ensure that the gateway contract cannot be updated if the user is not an admin.
The code changes are approved.
156-177: LGTM!The changes add a new test case to ensure that the gateway contract cannot be updated if the gateway address is invalid.
The code changes are approved.
43-63: Verify the correctness of thequeryZRC20Gatewayfunction.The function
queryZRC20Gatewayis correctly implemented but ensure that it handles all possible error scenarios and edge cases.Run the following script to verify the function usage:
Verification successful
Function
queryZRC20Gatewayis correctly implemented and used.The function
queryZRC20Gatewayis used within test assertions to verify gateway addresses, and its implementation handles errors appropriately. The usage is consistent with its intended purpose in the test cases.
- The function is defined and used in
x/fungible/keeper/msg_server_update_gateway_contract_test.go.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all function calls to `queryZRC20Gateway` match the expected usage. # Test: Search for the function usage. Expect: Only occurrences of the expected usage. rg --type go -A 5 $'queryZRC20Gateway'Length of output: 1998
e2e/runner/accounting.go (2)
173-183: LGTM!The changes optimize the function by preventing unnecessary balance checks for the new ERC20 custody contract.
The code changes are approved.
176-183: Verify the correctness of the new logic.The new logic correctly checks if the
ERC20CustodyAddrandERC20CustodyV2Addrare different before querying the balance of the new contract. Ensure that this logic handles all possible error scenarios and edge cases.Run the following script to verify the function usage:
Verification successful
The logic in
checkERC20TSSBalanceis correctly implemented. The function handles balance retrieval errors and ensures that the total balance is checked against the total supply, covering necessary edge cases. The logic for comparing addresses before querying balances is sound. No issues were found.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all function calls to `checkERC20TSSBalance` match the expected usage. # Test: Search for the function usage. Expect: Only occurrences of the expected usage. rg --type go -A 5 $'checkERC20TSSBalance'Length of output: 609
Script:
#!/bin/bash # Extract the full implementation of the `checkERC20TSSBalance` function to analyze error handling and edge case management. ast-grep --lang go --pattern $'func (r *E2ERunner) checkERC20TSSBalance() error { $$$ }'Length of output: 1954
e2e/runner/v2_migration.go (8)
20-48: LGTM!The function
RunV2Migrationis comprehensive and covers all necessary steps for the v2 migration.The code changes are approved.
50-68: LGTM!The function
upgradeZRC20scorrectly upgrades all ZRC20s to the new version.The code changes are approved.
77-123: LGTM!The function
upgradeZRC20correctly upgrades a ZRC20 to the new version.The code changes are approved.
125-203: LGTM!The function
migrateERC20CustodyFundscorrectly migrates all funds of the ERC20 custody contract to the new version.The code changes are approved.
70-75: LGTM!The interface
zrc20Callercorrectly defines the necessary functions to call ZRC20 functions.The code changes are approved.
126-203: Verify the correctness of each step inmigrateERC20CustodyFunds.The function
migrateERC20CustodyFundsincludes multiple steps for migrating ERC20 custody funds. Ensure that each step handles all possible error scenarios and edge cases.Run the following script to verify the function usage:
Verification successful
Verify error handling and edge cases in
migrateERC20CustodyFunds.The
migrateERC20CustodyFundsfunction is defined and used only withine2e/runner/v2_migration.go. Since it is not invoked elsewhere, focus on ensuring robust error handling and coverage of edge cases within the function itself. Verify that each step checks for errors and handles them appropriately.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all function calls to `migrateERC20CustodyFunds` match the expected usage. # Test: Search for the function usage. Expect: Only occurrences of the expected usage. rg --type go -A 5 $'migrateERC20CustodyFunds'Length of output: 728
22-48: Verify the correctness of each step inRunV2Migration.The function
RunV2Migrationincludes multiple steps for the v2 migration. Ensure that each step handles all possible error scenarios and edge cases.Run the following script to verify the function usage:
Verification successful
Enhance Error Handling and Edge Case Coverage in
RunV2MigrationThe
RunV2Migrationfunction and its related functions effectively userequire.NoErrorto handle errors, ensuring that execution halts on failure. However, to robustly handle potential edge cases, consider the following improvements:
- Review Error Handling Strategy: Ensure that the current error handling covers potential edge cases such as network failures, transaction timeouts, or unexpected states.
- Implement Retries: For known transient issues like network failures, consider implementing retry logic to enhance resilience.
- Alternative Flows: Develop alternative flows or fallbacks for critical steps that might encounter unexpected conditions.
By addressing these areas, the migration process will be more robust and reliable.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all function calls to `RunV2Migration` match the expected usage. # Test: Search for the function usage. Expect: Only occurrences of the expected usage. rg --type go -A 5 $'RunV2Migration'Length of output: 800
Script:
#!/bin/bash # Extract the implementation of RunV2Migration to analyze error handling. ast-grep --lang go --pattern 'func (r *E2ERunner) RunV2Migration() { $$$ }' # Extract implementations of related functions to check for error handling. ast-grep --lang go --pattern 'func (r *E2ERunner) AddAuthorization($_) { $$$ }' ast-grep --lang go --pattern 'func (r *E2ERunner) SetupEVMV2() { $$$ }' ast-grep --lang go --pattern 'func (r *E2ERunner) upgradeZRC20s() { $$$ }' ast-grep --lang go --pattern 'func (r *E2ERunner) SetZEVMContractsV2() { $$$ }' ast-grep --lang go --pattern 'func (r *E2ERunner) migrateERC20CustodyFunds() { $$$ }'Length of output: 18769
79-123: Verify the correctness of each step inupgradeZRC20.The function
upgradeZRC20includes multiple steps for upgrading a ZRC20. Ensure that each step handles all possible error scenarios and edge cases.Run the following script to verify the function usage:
Verification successful
Review the Error Handling in
upgradeZRC20FunctionThe
upgradeZRC20function effectively usesrequire.NoErrorto handle errors, ensuring that any failure stops execution immediately. While this is suitable for testing, consider implementing more robust error handling and retry logic if the function is intended for production use. This will help manage potential edge cases such as network failures or unexpected conditions.
- Ensure that the function's error handling aligns with its intended use, especially if used outside a test environment.
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify all function calls to `upgradeZRC20` match the expected usage. # Test: Search for the function usage. Expect: Only occurrences of the expected usage. rg --type go -A 5 $'upgradeZRC20'Length of output: 2014
Script:
#!/bin/bash # Extract the implementation of the `upgradeZRC20` function to analyze error handling and edge cases. ast-grep --lang go --pattern $'func (r *E2ERunner) upgradeZRC20($_, $_, $_, $_) { $$$ }' --jsonLength of output: 3456
e2e/runner/evm.go (2)
191-193: LGTM!The changes enhance the approval criteria and improve code readability.
The code changes are approved.
208-210: LGTM!The changes enhance the approval criteria and improve code readability.
The code changes are approved.
contrib/localnet/orchestrator/start-zetae2e.sh (4)
94-98: LGTM!The changes follow a consistent pattern and appropriately use
yqandgethcommands.The code changes are approved.
99-103: LGTM!The changes follow a consistent pattern and appropriately use
yqandgethcommands.The code changes are approved.
104-108: LGTM!The changes follow a consistent pattern and appropriately use
yqandgethcommands.The code changes are approved.
109-113: LGTM!The changes follow a consistent pattern and appropriately use
yqandgethcommands.The code changes are approved.
.github/workflows/e2e.yml (5)
56-59: LGTM!The addition of the new input parameter is consistent with the existing parameters and enhances the workflow's capability.
The code changes are approved.
81-81: LGTM!The addition of the new output variable is consistent with the existing output variables and enhances the workflow's capability.
The code changes are approved.
106-106: LGTM!The changes ensure that the new migration test can be referenced and utilized in the job steps, enhancing the control flow of the workflow.
The code changes are approved.
121-121: LGTM!The changes ensure that the new migration test can be referenced and utilized in the job steps, enhancing the control flow of the workflow.
The code changes are approved.
186-188: LGTM!The addition of the new make-target is consistent with the existing make-targets and enhances the workflow's capability.
The code changes are approved.
e2e/config/config.go (3)
64-76: LGTM!The new fields are correctly added to the
AdditionalAccountsstruct.The code changes are approved.
232-235: LGTM!The new fields are correctly included in the returned slice.
The code changes are approved.
328-343: LGTM!The new fields are correctly initialized in the
GenerateKeysmethod.The code changes are approved.
zetaclient/chains/bitcoin/observer/inbound.go (1)
60-63: LGTM!The change improves the clarity of the logs by preventing unnecessary error messages.
The code changes are approved.
Makefile (1)
317-325: LGTM!The new target is correctly defined and enhances the functionality of the upgrade testing suite.
The code changes are approved.
go.mod (1)
46-46: LGTM!The dependency update is appropriate and necessary for maintaining compatibility with the latest protocol contracts.
The code changes are approved.
contrib/localnet/scripts/start-zetacored.sh (5)
257-259: Verify the use ofyqcommand.Ensure that the
yqcommand is available in the environment where this script will be executed. If not, consider adding a check or installing it within the script.
257-259: LGTM!The addition of the v2 ether tester account is correctly implemented.
The code changes are approved.
260-262: LGTM!The addition of the v2 erc20 tester account is correctly implemented.
The code changes are approved.
263-265: LGTM!The addition of the v2 ether revert tester account is correctly implemented.
The code changes are approved.
266-268: LGTM!The addition of the v2 erc20 revert tester account is correctly implemented.
The code changes are approved.
cmd/zetae2e/local/local.go (7)
46-46: LGTM!The addition of the
flagTestV2Migrationconstant is appropriate and necessary for enabling v2 migration tests.The code changes are approved.
81-81: LGTM!The registration of the
flagTestV2Migrationflag within theNewLocalCmdfunction is correctly implemented.The code changes are approved.
109-109: Verify error handling inRunV2Migrationmethod.Ensure that the
RunV2Migrationmethod handles errors appropriately to prevent potential issues during the migration process.
242-254: LGTM!The logic for handling the
testV2Migrationflag is correctly implemented and necessary for facilitating the v2 migration process.The code changes are approved.
379-381: Verify error handling inUpdateChainParamsV2Contractsfunction.Ensure that the
UpdateChainParamsV2Contractsfunction handles errors appropriately to prevent potential issues during the v2 tests.
383-384: Verify error handling instartV2Testsfunction.Ensure that the
startV2Testsfunction handles errors appropriately to prevent potential issues during the v2 tests.
379-384: LGTM!The logic for running v2 tests is correctly implemented and necessary for ensuring that v2 functionalities are validated.
The code changes are approved.
zetaclient/orchestrator/orchestrator.go (1)
392-401: Verify the impact on Prometheus gauge update logic.Ensure that the change in the order of operations does not affect the accuracy of the Prometheus gauge update logic for pending transactions.
Run the following script to verify the impact:
Verification successful
Prometheus Gauge Update Logic Verified
The current order of operations ensures that the Prometheus gauge accurately reflects the state of
cctxList, even when the list is empty. The logic is sound, and no issues were found with the update process.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the impact on Prometheus gauge update logic. # Test: Search for the Prometheus gauge update logic. Expect: No issues in the order of operations. rg --type go -A 5 $'metrics.PendingTxsPerChain'Length of output: 440
Co-authored-by: skosito <skostic9242@gmail.com>
Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com>
Co-authored-by: Dmitry S <11892559+swift1337@users.noreply.github.com>
Description
Add
that will:
Run same workflow as upgrade test light from v18 (to setup environment with v1 contracts)
After upgrade:
Add a few fixes:
updateGatewayAddressin each ZRC20s inMsgUpdateGatewayContract#2652Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores