test: configure Solana gateway program id for E2E tests #3154
Conversation
📝 WalkthroughWalkthroughThis pull request introduces several enhancements, fixes, and refactoring efforts across the ZetaChain node. Key features include the whitelisting of SPL tokens on Solana, improvements in build reproducibility, and the integration of SPL deposits and withdrawals. The testing framework has been enhanced with new end-to-end tests for Solana configurations. Refactoring includes the removal of the HSM signer from the zetaclient and updates to the emissions module. Fixes address issues related to transaction processing and configuration resolution. Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
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
|
ws4charlie
added
chain:solana
SOLANA_TESTS
ws4charlie
requested review from
brewmaster012,
kingpinXD,
lumtis,
skosito,
swift1337 and
fbac
as code owners
ws4charlie
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (16)
pkg/contracts/solana/gateway.go (3)
Line range hint
1-1: Fix typo in package documentationThere's a typo in the package documentation: "privides" should be "provides".
-// Package solana privides structures and constants that are used when interacting with the gateway program on Solana chain. +// Package solana provides structures and constants that are used when interacting with the gateway program on Solana chain.
29-44: Consider grouping related discriminatorsThe discriminators are well-documented but could be organized better. Consider grouping them logically:
- Initialization discriminators (Initialize, InitializeRentPayer)
- Transaction discriminators (Deposit, DepositSPL, Withdraw, WithdrawSPL)
- Management discriminators (WhitelistSplMint)
var ( // Initialization DiscriminatorInitialize = idlgateway.IDLGateway.GetDiscriminator("initialize") DiscriminatorInitializeRentPayer = idlgateway.IDLGateway.GetDiscriminator("initialize_rent_payer") // Transaction Operations DiscriminatorDeposit = idlgateway.IDLGateway.GetDiscriminator("deposit") DiscriminatorDepositSPL = idlgateway.IDLGateway.GetDiscriminator("deposit_spl_token") DiscriminatorWithdraw = idlgateway.IDLGateway.GetDiscriminator("withdraw") DiscriminatorWithdrawSPL = idlgateway.IDLGateway.GetDiscriminator("withdraw_spl_token") // Management Operations DiscriminatorWhitelistSplMint = idlgateway.IDLGateway.GetDiscriminator("whitelist_spl_mint") )
Line range hint
47-73: Consider adding input validation for gateway addressThe utility functions are well-implemented, but
ParseGatewayWithPDAcould benefit from additional validation before processing the gateway address.func ParseGatewayWithPDA(gatewayAddress string) (solana.PublicKey, solana.PublicKey, error) { var gatewayID, pda solana.PublicKey + if gatewayAddress == "" { + return gatewayID, pda, errors.New("gateway address cannot be empty") + } + // decode gateway address gatewayID, err := solana.PublicKeyFromBase58(gatewayAddress) if err != nil { return gatewayID, pda, errors.Wrap(err, "unable to decode address") }cmd/zetae2e/config/config.go (2)
Line range hint
58-87: Consider refactoring for improved maintainability.The function could benefit from being split into smaller, focused helper functions for each blockchain platform.
Consider refactoring like this:
func ExportContractsFromRunner(r *runner.E2ERunner, conf config.Config) config.Config { - // copy contracts from deployer runner - conf.Contracts.Solana.GatewayProgramID = config.DoubleQuotedString(r.GatewayProgram.String()) - // ... rest of the assignments + conf = exportSolanaContracts(r, conf) + conf = exportEVMContracts(r, conf) + conf = exportZEVMContracts(r, conf) + conf = exportV2Contracts(r, conf) return conf } +func exportSolanaContracts(r *runner.E2ERunner, conf config.Config) config.Config { + conf.Contracts.Solana.GatewayProgramID = config.DoubleQuotedString(r.GatewayProgram.String()) + conf.Contracts.Solana.SPLAddr = config.DoubleQuotedString(r.SPLAddr.String()) + return conf +}
Line range hint
82-87: Enhance documentation for v2 contracts.The v2 contracts section would benefit from documentation explaining the upgrade path and differences from v1.
Add comments like this:
- // v2 + // v2 contracts represent the upgraded protocol version with enhanced features: + // - Improved gateway implementation + // - New custody contract with additional security measures + // - Updated test DApps compatible with v2 protocolcmd/zetae2e/config/localnet.yml (3)
101-102: LGTM! Consider adding documentation.The new
contractssection provides a clean structure for configuration. Consider adding a comment block explaining the purpose and configuration options of this section.
103-104: Consider parameterizing the gateway program ID.While using the old program ID (
94U5AHQMKkV5txNJ17QPXWoh474PheGou6cNP2FEuL1d) is valid for E2E tests, hardcoding it might limit flexibility. Consider:
- Using environment variables
- Adding a comment explaining why this specific ID is used
- Creating separate configuration files for different environments (e.g.,
localnet.yml,testnet.yml)This would make it easier to manage different program IDs across environments.
105-105: Address empty SPL configuration and add newline.Two issues need attention:
- The
splconfiguration is empty without explanation- The file is missing a newline at EOF
Apply this diff to fix these issues:
solana: gateway_program_id: "94U5AHQMKkV5txNJ17QPXWoh474PheGou6cNP2FEuL1d" - spl: "" + # SPL token configuration for E2E tests + spl: "" +🧰 Tools
🪛 yamllint
[error] 105-105: no new line character at the end of file
(new-line-at-end-of-file)
zetaclient/chains/solana/observer/inbound_test.go (2)
74-74: Add documentation explaining gateway address usageConsider adding a comment explaining why this specific test uses the old gateway address. This will help future maintainers understand the relationship between the test data and the gateway address configuration.
+ // Using old gateway address as the test data is from a historical devnet transaction + // that was processed with this specific gateway program ID chainParams.GatewayAddress = testutils.OldSolanaGatewayAddressDevnet
74-74: Consider standardizing gateway address usage across testsThe test file uses different approaches for gateway addresses in different tests:
Test_FilterInboundEventAndVoteusesGatewayAddressTestTest_FilterInboundEventsusestestutils.OldSolanaGatewayAddressDevnetTest_BuildInboundVoteMsgFromEventusessample.SolanaAddress(t)Consider standardizing the approach or documenting why different tests need different gateway addresses.
Suggestions:
- Create a test helper that provides appropriate gateway addresses based on the test scenario
- Add constants for different gateway addresses with clear naming
- Document the rationale for using different addresses in different tests
cmd/zetae2e/config/local.yml (1)
122-122: Add newline at end of fileAdd a newline character at the end of the file to comply with YAML formatting standards.
Apply this change:
spl: "" +🧰 Tools
🪛 yamllint
[error] 122-122: no new line character at the end of file
(new-line-at-end-of-file)
cmd/zetae2e/config/contracts.go (1)
Line range hint
33-39: Ensure consistent error handling across contract setupsThe Solana contract setup lacks error handling compared to EVM/ZEVM sections. Consider applying the same level of error checking for consistency.
// set Solana contracts if c := conf.Contracts.Solana.GatewayProgramID; c != "" { - r.GatewayProgram = solana.MustPublicKeyFromBase58(c.String()) + pubKey, err := solana.PublicKeyFromBase58(c.String()) + if err != nil { + return fmt.Errorf("invalid GatewayProgramID: %w", err) + } + r.GatewayProgram = pubKey } if c := conf.Contracts.Solana.SPLAddr; c != "" { - r.SPLAddr = solana.MustPublicKeyFromBase58(c.String()) + pubKey, err := solana.PublicKeyFromBase58(c.String()) + if err != nil { + return fmt.Errorf("invalid SPLAddr: %w", err) + } + r.SPLAddr = pubKey }e2e/runner/solana.go (1)
Line range hint
1-400: Consider enhancing test reliability with retries and timeouts.The E2E test utilities could benefit from additional reliability mechanisms:
- Add retry mechanisms for transient Solana RPC failures
- Implement configurable timeouts for transaction confirmations
- Add validation for PDA account data after creation
Would you like me to provide a detailed implementation for these enhancements?
cmd/zetae2e/local/local.go (2)
227-230: Consider adding validation for the gateway program ID.The implementation correctly configures the Solana gateway program ID from the configuration. However, consider adding validation to ensure the program ID is well-formed before passing it to
SetupSolana.+// Validate Solana gateway program ID +if err := validateSolanaAddress(conf.Contracts.Solana.GatewayProgramID.String()); err != nil { + logger.Print("❌ invalid Solana gateway program ID: %v", err) + os.Exit(1) +} deployerRunner.SetupSolana( conf.Contracts.Solana.GatewayProgramID.String(), conf.AdditionalAccounts.UserSolana.SolanaPrivateKey.String(), )
226-226: Track the TODO comment in the issue system.The TODO comment references issue #2762 for simplifying this file. Consider breaking down the test orchestration into smaller, more focused files for better maintainability.
Would you like me to create a new GitHub issue to track the implementation of these test orchestration improvements?
zetaclient/orchestrator/orchestrator_test.go (1)
128-129: Consider consolidating gateway address configurationThe gateway address configuration for Solana and TON chains are set separately. Consider refactoring to use a common pattern for consistency.
- solChainParams.GatewayAddress = testutils.GatewayAddresses[solChain.ChainId] - tonChainParams.GatewayAddress = sample.GenerateTONAccountID().ToRaw() + // Configure gateway addresses using chain-specific utilities + chainGatewayAddresses := map[int64]string{ + solChain.ChainId: testutils.GatewayAddresses[solChain.ChainId], + tonChain.ChainId: sample.GenerateTONAccountID().ToRaw(), + } + for chainID, address := range chainGatewayAddresses { + if params := lo.FindOrNil([]observertypes.ChainParams{solChainParams, tonChainParams}, + func(p observertypes.ChainParams) bool { return p.ChainId == chainID }); params != nil { + params.GatewayAddress = address + } + }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (14)
changelog.md(1 hunks)cmd/zetae2e/config/config.go(1 hunks)cmd/zetae2e/config/contracts.go(1 hunks)cmd/zetae2e/config/local.yml(1 hunks)cmd/zetae2e/config/localnet.yml(1 hunks)cmd/zetae2e/local/local.go(1 hunks)e2e/config/config.go(1 hunks)e2e/runner/setup_solana.go(2 hunks)e2e/runner/solana.go(2 hunks)pkg/contracts/solana/gateway.go(1 hunks)pkg/contracts/solana/inbound_test.go(2 hunks)zetaclient/chains/solana/observer/inbound_test.go(1 hunks)zetaclient/orchestrator/orchestrator_test.go(2 hunks)zetaclient/testutils/constant.go(1 hunks)
🧰 Additional context used
📓 Path-based instructions (11)
cmd/zetae2e/config/config.go (1)
Pattern **/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
cmd/zetae2e/config/contracts.go (1)
Pattern **/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
cmd/zetae2e/local/local.go (1)
Pattern **/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
e2e/config/config.go (1)
Pattern **/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
e2e/runner/setup_solana.go (1)
Pattern **/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
e2e/runner/solana.go (1)
Pattern **/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
pkg/contracts/solana/gateway.go (1)
Pattern **/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
pkg/contracts/solana/inbound_test.go (1)
Pattern **/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
zetaclient/chains/solana/observer/inbound_test.go (1)
Pattern **/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
zetaclient/orchestrator/orchestrator_test.go (1)
Pattern **/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
zetaclient/testutils/constant.go (1)
Pattern **/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
🪛 yamllint
cmd/zetae2e/config/local.yml
[error] 122-122: no new line character at the end of file
(new-line-at-end-of-file)
cmd/zetae2e/config/localnet.yml
[error] 105-105: no new line character at the end of file
(new-line-at-end-of-file)
🔇 Additional comments (18)
pkg/contracts/solana/inbound_test.go (2)
82-82: Verify SPL token deposit compatibility.
The gateway address change is consistent with the previous test. However, since this test involves SPL tokens, we should verify that OldSolanaGatewayAddressDevnet supports SPL token deposits correctly.
✅ Verification successful
Gateway address change is compatible with SPL token deposits
The verification confirms that:
- The test data shows successful SPL token deposits through the gateway program
- The gateway program handles SPL deposits through a dedicated
deposit_spl_tokeninstruction - No special gateway address requirements exist for SPL tokens versus native tokens
The gateway address change is safe as it only affects the test configuration and the gateway program handles both native and SPL token deposits through the same gateway address.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for SPL token specific gateway configurations and test data
# Look for SPL token specific configurations or tests
echo "Checking for SPL token specific gateway configurations:"
rg -A 5 "SPL.*[Gg]ateway|[Gg]ateway.*SPL" --type go
# Check if the SPL test data contains gateway address references
echo -e "\nChecking SPL test data:"
cat pkg/contracts/solana/testdata/aY8yLDze*.json | jq -r 'if has("gatewayAddress") then .gatewayAddress else empty end'
Length of output: 5530
Script:
#!/bin/bash
# Let's verify the test data content and gateway address usage
# Check the content of the SPL test data file
echo "Checking SPL test data content:"
cat "pkg/contracts/solana/testdata/aY8yLDze"*.json
# Look for gateway address usage in SPL deposit tests
echo -e "\nChecking gateway address usage in SPL deposit tests:"
rg -B 5 -A 5 "OldSolanaGatewayAddressDevnet.*SPL|SPL.*OldSolanaGatewayAddressDevnet" --type go
# Check for any SPL deposit specific configurations
echo -e "\nChecking SPL deposit configurations:"
rg -B 3 -A 3 "DepositSPL.*struct|DepositSPL.*interface" --type go
Length of output: 6951
50-50: Verify test data compatibility with new gateway address.
The gateway address change looks good, but we should ensure the test data in testdata/MS3MPLN7...json is compatible with OldSolanaGatewayAddressDevnet.
✅ Verification successful
Gateway address in test data matches the constant value
The test data files and gateway address are consistent. The transaction data shows interactions with program ID 94U5AHQMKkV5txNJ17QPXWoh474PheGou6cNP2FEuL1d, which matches exactly with the OldSolanaGatewayAddressDevnet constant being used in the test. Both deposit and SPL deposit test cases are properly configured with the correct gateway address.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if other test files need similar gateway address updates and verify test data compatibility
# Find all test files that might reference gateway addresses
echo "Checking for other test files that might need updates:"
rg -l "GatewayAddress" --type go --glob "*_test.go"
# Check if the test data contains any gateway address references
echo -e "\nChecking test data for gateway address references:"
rg -l "gatewayAddress|GatewayAddress" pkg/contracts/solana/testdata/
Length of output: 5530
Script:
#!/bin/bash
# Let's check the specific test data file and gateway address references more precisely
# First, find the exact test data file name
echo "Looking for test data files in solana directory:"
fd -t f -e json . pkg/contracts/solana/testdata/
# Then check its contents
echo -e "\nChecking gateway address in test data:"
find pkg/contracts/solana/testdata/ -type f -name "*.json" -exec sh -c 'echo "=== $1 ==="; cat "$1" | jq .' {} \;
# Check for gateway address usage in the test file
echo -e "\nChecking gateway address usage in test file:"
rg -A 5 "GatewayAddress" pkg/contracts/solana/inbound_test.go
Length of output: 1290
Script:
#!/bin/bash
# Let's examine the contents of the test data files specifically
echo "=== Contents of first test file ==="
cat "pkg/contracts/solana/testdata/MS3MPLN7hkbyCZFwKqXcg8fmEvQMD74fN6Ps2LSWXJoRxPW5ehaxBorK9q1JFVbqnAvu9jXm6ertj7kT7HpYw1j.json"
echo -e "\n=== Contents of second test file ==="
cat "pkg/contracts/solana/testdata/aY8yLDze6nHSRi7L5REozKAZY1aAyPJ6TfibiqQL5JGwgSBkYux5z5JfXs5ed8LZqpXUy4VijoU3x15mBd66ZGE.json"
echo -e "\n=== Checking OldSolanaGatewayAddressDevnet constant ==="
rg "OldSolanaGatewayAddressDevnet" -A 2
Length of output: 6933
pkg/contracts/solana/gateway.go (1)
Line range hint 1-1: Verify all references to removed SolanaGatewayProgramID constant
The removal of the hardcoded SolanaGatewayProgramID constant aligns with the PR objectives. Let's verify all references have been updated.
✅ Verification successful
Removed constant appears only in test data and configuration files
The SolanaGatewayProgramID constant has been successfully removed, and all remaining references to the program ID 94U5AHQMKkV5txNJ17QPXWoh474PheGou6cNP2FEuL1d are found only in:
- Test data files (
testdata/directories) - Test utilities (
zetaclient/testutils/constant.go) - Configuration files (
cmd/zetae2e/config/)
These references are expected and do not require updates as they represent historical test data and configurable values.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any remaining references to SolanaGatewayProgramID
rg "SolanaGatewayProgramID"
# Search for potential string literals that might be the old program ID
rg "94U5AHQMKkV5txNJ17QPXWoh474PheGou6cNP2FEuL1d"
Length of output: 3909
zetaclient/testutils/constant.go (2)
42-43: LGTM! Well-documented constant declaration.
The constant name and documentation clearly indicate its purpose as the old gateway address for testing purposes.
47-49: Consider environment-specific addresses and configuration approach.
A few considerations:
- Using identical addresses for both devnet and mainnet environments might lead to confusion or issues. Consider using distinct addresses for better separation of concerns.
- Since the PR objectives mention making the gateway program ID configurable, consider moving these values to a configuration file instead of hardcoding them here.
Let's verify the usage of these addresses across the codebase:
cmd/zetae2e/config/config.go (1)
Line range hint 58-87: LGTM! Consistent string formatting applied across all contract addresses.
The implementation ensures uniform handling of contract addresses using config.DoubleQuotedString.
zetaclient/chains/solana/observer/inbound_test.go (1)
74-74: Verify test data compatibility with gateway address
The test uses archived transaction data from a specific Solana devnet transaction. We should verify that this transaction data is compatible with the old gateway address being used.
✅ Verification successful
Test data is correctly aligned with the gateway address
The test data files contain transactions that explicitly use the old gateway address 94U5AHQMKkV5txNJ17QPXWoh474PheGou6cNP2FEuL1d. This matches exactly with the testutils.OldSolanaGatewayAddressDevnet constant being used in the test, ensuring compatibility between the test data and the gateway address configuration.
Key evidence from test data:
- Transaction's program ID (accountKeys[3]) matches the old gateway address
- Log messages show successful execution with the same program ID
- The constant is properly documented in
testutils/constant.go
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if the test data contains references to the old gateway address
# Search for the old gateway address in the test data
rg -A 5 "94U5AHQMKkV5txNJ17QPXWoh474PheGou6cNP2FEuL1d" "${TestDataDir}"
# Check the transaction data file
fd -g "*MS3MPLN7hkbyCZFwKqXcg8fmEvQMD74fN6Ps2LSWXJoRxPW5ehaxBorK9q1JFVbqnAvu9jXm6ertj7kT7HpYw1j*" "${TestDataDir}" --exec cat {}
Length of output: 323
Script:
#!/bin/bash
# Let's first locate the test data directory and files
fd -t f -e json "MS3MPLN7hkbyCZFwKqXcg8fmEvQMD74fN6Ps2LSWXJoRxPW5ehaxBorK9q1JFVbqnAvu9jXm6ertj7kT7HpYw1j"
# Search for any references to gateway addresses in the test file
rg -A 5 "GatewayAddress" zetaclient/chains/solana/observer/inbound_test.go
# Look for the test data path pattern in the test file
rg "TestDataDir" zetaclient/chains/solana/observer/inbound_test.go
# Check for any constants or test data setup
rg "const.*TestData" zetaclient/chains/solana/observer/
Length of output: 1501
Script:
#!/bin/bash
# Let's examine the test data files we found
cat "pkg/contracts/solana/testdata/MS3MPLN7hkbyCZFwKqXcg8fmEvQMD74fN6Ps2LSWXJoRxPW5ehaxBorK9q1JFVbqnAvu9jXm6ertj7kT7HpYw1j.json"
cat "zetaclient/testdata/solana/chain_901_inbound_tx_result_MS3MPLN7hkbyCZFwKqXcg8fmEvQMD74fN6Ps2LSWXJoRxPW5ehaxBorK9q1JFVbqnAvu9jXm6ertj7kT7HpYw1j.json"
# Let's also check the testutils package for the gateway address constant
rg "OldSolanaGatewayAddressDevnet" -A 2
Length of output: 5654
e2e/runner/setup_solana.go (2)
30-30: LGTM: Method signature updated appropriately
The addition of the gatewayID parameter aligns with the PR objective to make the gateway program ID configurable, improving test flexibility.
144-144: LGTM: Verify chain params propagation
The GatewayAddress update correctly uses the configured program ID. However, let's verify the chain params update process:
✅ Verification successful
GatewayAddress update is correctly propagated
The verification confirms that the GatewayAddress parameter is consistently handled across the codebase:
- Protocol-level definition in
x/observer/types/params.pb.go - Proper equality checks in
x/observer/types/chain_params.go - Consistent usage in tests with appropriate test fixtures
- Parallel implementation for EVM chains in
e2e/runner/v2_setup_zeta.go
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the chain params update logic across the codebase
# Look for other places where GatewayAddress might be set or used
# Check for other GatewayAddress assignments
rg -g '*.go' 'GatewayAddress.*=' --type go
# Check for chain params tests that might need updating
rg -g '*_test.go' 'ChainParams.*GatewayAddress' --type go
Length of output: 4089
cmd/zetae2e/config/local.yml (2)
121-121: Verify the gateway program ID configuration
According to issue #3148, this gateway program ID (94U5AHQMKkV5txNJ17QPXWoh474PheGou6cNP2FEuL1d) corresponds to an old deployer key. While it's appropriate for E2E tests since we can't use the production ID (ZETAjseVjuFsxdRxo6MmTCvqFwb3ZHUx56Co3vCmGis), we should document this decision.
Consider adding a comment in the YAML file to explain why this specific ID is used for E2E tests. For example:
solana:
+ # Using old deployer key for E2E tests as production key cannot be used
gateway_program_id: "94U5AHQMKkV5txNJ17QPXWoh474PheGou6cNP2FEuL1d"122-122: Clarify the purpose of the empty SPL configuration
The spl: "" entry appears to be a placeholder. Please clarify its intended use or remove it if not needed.
Run the following to check if this configuration is referenced elsewhere:
✅ Verification successful
Let me search for any SPL-related configurations or usage patterns to better understand the context.
Empty SPL configuration is intentional for local environment setup
The empty SPL configuration (spl: "") is a valid placeholder used in local environment configurations. This is evidenced by:
- It's consistently empty in both
local.ymlandlocalnet.yml - The codebase has extensive SPL (Solana Program Library) token support for testing and deployment
- The configuration is used by the E2E test framework to optionally specify SPL token addresses (
SPLAddrin config structs)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for references to solana.spl configuration
rg -l "solana\W+spl" || echo "No references found"
Length of output: 71
Script:
#!/bin/bash
# Search for any SPL related configurations or patterns
rg -i "spl[\"'\s:]" -A 2
# Also check for any SPL related imports or code
ast-grep --pattern 'import $_ from "$_spl$_"'
Length of output: 21223
🧰 Tools
🪛 yamllint
[error] 122-122: no new line character at the end of file
(new-line-at-end-of-file)
cmd/zetae2e/config/contracts.go (1)
Line range hint 1-300: Verify contract addresses in configuration files
The changes make the Solana gateway program ID configurable. Let's verify that all configuration files have been updated with valid addresses.
✅ Verification successful
Solana gateway program ID configuration is properly implemented
The verification confirms that:
- The Solana gateway program ID is consistently configured in both local and localnet configuration files
- The address
94U5AHQMKkV5txNJ17QPXWoh474PheGou6cNP2FEuL1dis properly referenced across the codebase:- Used in test data files for validation
- Defined as
OldSolanaGatewayAddressDevnetin testutils - Correctly integrated in the gateway contract configuration
- The implementation properly handles the program ID through the configuration system, with appropriate error handling and type safety
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check configuration files for Solana gateway program ID
# Expected: Find gateway_program_id in configuration files
echo "Checking configuration files for gateway_program_id:"
rg -l "gateway_program_id" --type yaml
echo -e "\nChecking the values:"
rg "gateway_program_id:" -A 1 --type yaml
Length of output: 604
Script:
#!/bin/bash
# Let's verify if this Solana address is valid and consistent across the codebase
# First, check if this address is referenced in any Go or Rust files
echo "Checking for Solana address usage in code:"
rg "94U5AHQMKkV5txNJ17QPXWoh474PheGou6cNP2FEuL1d"
# Then check if there are any other Solana gateway program IDs that might conflict
echo -e "\nChecking for other potential gateway program IDs:"
rg -i "solana.*gateway.*program" -B 1 -A 1
Length of output: 8207
e2e/runner/solana.go (2)
35-35: LGTM! Verify rent payer PDA consistency.
The change to use r.GatewayProgram for rent payer PDA computation is correct.
Let's verify rent payer PDA computation consistency:
#!/bin/bash
# Description: Verify rent payer PDA computation consistency
# Search for any other rent payer PDA computations
# Look for FindProgramAddress calls with RentPayerPDASeed
rg -A 2 "FindProgramAddress.*RentPayerPDASeed"
# Look for potential rent-related PDA computations
ast-grep --pattern 'FindProgramAddress($$$rent$$$)'24-24: LGTM! Verify PDA derivation consistency.
The change to use r.GatewayProgram instead of hardcoded program ID is correct and aligns with the PR objectives.
Let's verify that the PDA derivation remains consistent across different environments:
✅ Verification successful
PDA derivation consistency verified across codebase
The change to use r.GatewayProgram is consistent with all other PDA derivations in the codebase. The verification shows:
- All FindProgramAddress calls use the same gateway program ID pattern
- The PDASeed constant is consistently defined in
pkg/contracts/solana/gateway.go - The change aligns with the global configuration pattern used throughout the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify PDA derivation consistency across configurations
# Search for any other PDA derivations using different program IDs
# Look for FindProgramAddress calls with the PDASeed
rg -A 2 "FindProgramAddress.*PDASeed"
# Look for other potential gateway program ID references
rg -l "94U5AHQMKkV5txNJ17QPXWoh474PheGou6cNP2FEuL1d|ZETAjseVjuFsxdRxo6MmTCvqFwb3ZHUx56Co3vCmGis"
Length of output: 197
Script:
#!/bin/bash
# Let's try a more comprehensive search for PDA derivations and program IDs
# Search for FindProgramAddress calls
rg -A 3 "FindProgramAddress"
# Search for gateway program related constants or configurations
rg -A 2 "GatewayProgram|gateway.*program"
# Look for any PDA seed definitions
rg "seed.*:=.*byte"
Length of output: 12631
e2e/config/config.go (1)
123-123: LGTM: Well-structured configuration field addition
The implementation correctly uses DoubleQuotedString type for consistent YAML marshaling and follows the established pattern in the codebase for address fields.
Let's verify the configuration loading:
✅ Verification successful
Let me verify the configuration loading implementation by checking how the field is used in the codebase.
Configuration field is properly integrated and utilized
The verification confirms that:
- The
GatewayProgramIDfield is correctly configured in both local and localnet YAML configurations - The field is properly utilized in the codebase:
- Used in configuration loading (
cmd/zetae2e/config/contracts.go) - Properly set during initialization (
cmd/zetae2e/config/config.go) - Accessed in local implementation (
cmd/zetae2e/local/local.go)
- Used in configuration loading (
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the gateway program ID configuration is properly loaded from YAML
# Check if the gateway_program_id is present in configuration files
echo "Checking configuration files for gateway_program_id..."
rg -l "gateway_program_id:" --type yaml
# Verify the structure matches our implementation
echo "Verifying configuration structure..."
rg -A 2 "solana:" --type yaml
Length of output: 1737
Script:
#!/bin/bash
# Check how GatewayProgramID is used in the code
echo "Checking usage of GatewayProgramID..."
rg -p "GatewayProgramID" -t go
# Check the configuration loading implementation
echo "Checking configuration loading implementation..."
ast-grep --pattern 'func $_(config $Config) $_ {
$$$
}'
Length of output: 680
zetaclient/orchestrator/orchestrator_test.go (2)
43-43: LGTM: Gateway address configuration aligns with PR objectives
The change correctly implements the configurable Solana gateway address by sourcing it from testutils.GatewayAddresses, which aligns with the PR's goal of removing hardcoded values.
Line range hint 1-600: Verify test coverage for edge cases
The test suite comprehensively covers the happy path scenarios but could benefit from additional edge cases:
- Invalid gateway addresses
- Chain ID mismatches
- Network-specific address validation
✅ Verification successful
Based on the shell script results, I can see that the test suite already includes comprehensive error handling tests covering:
- Invalid chain scenarios (BSC, BTC testnet, Solana Devnet)
- Missing observer/signer error cases
- Invalid rate limiter input validation
Let me verify the address validation specifically:
Let me check the validation implementations in the mock objects and chain-specific code:
Let me check one final aspect - the actual chain-specific address validation implementations:
Test coverage for edge cases is comprehensive and well-implemented
The test suite already includes thorough validation for addresses across different chains:
-
EVM chain validation:
- Invalid hex addresses for both 'from' and 'to' fields
- Empty address handling
- Connector and custody contract address validation
-
Solana chain validation:
- Invalid gateway address tests
- Address format validation
-
Bitcoin chain validation:
- Invalid revert address checks
- Address type support validation
-
TON chain validation:
- Gateway address validation through the standard interfaces
The implementation includes proper validation at both the test and runtime levels, with appropriate error messages and handling of chain-specific address formats.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check test coverage for edge cases
echo "Checking for existing edge case tests..."
# Look for error condition tests
rg -B 2 -A 2 "require.Error|assert.Error" zetaclient/orchestrator/orchestrator_test.go
# Look for invalid address tests
rg -B 2 -A 2 "Invalid|invalid|malformed" zetaclient/orchestrator/orchestrator_test.go
# Look for chain-specific validation
ast-grep --pattern 'func Test_$_($_) {
$$$
require.Error($_)
$$$
}'
Length of output: 2042
Script:
#!/bin/bash
# Check for address validation tests
rg -B 5 -A 5 "Address|address" zetaclient/orchestrator/orchestrator_test.go
# Look for validation in the implementation
rg -B 5 -A 5 "Address|address" zetaclient/orchestrator/orchestrator.go
Length of output: 7613
Script:
#!/bin/bash
# Check mock implementations for address validation
rg -B 5 -A 5 "SetGatewayAddress|SetZetaConnectorAddress|SetERC20CustodyAddress" zetaclient/testutils/mocks/
# Check chain-specific address validation
rg -B 5 -A 5 "Address.*valid|valid.*Address" pkg/chains/
Length of output: 3839
Script:
#!/bin/bash
# Check for address validation in chain implementations
rg -B 5 -A 5 "address.*valid|valid.*address" zetaclient/chains/
# Check interfaces for validation requirements
rg -B 5 -A 5 "address.*valid|valid.*address" zetaclient/chains/interfaces/
Length of output: 17662
changelog.md (1)
15-15: LGTM! The changelog entry is well-formatted and accurately describes the PR changes.
The entry follows the standard format and is correctly placed in the "Tests" section, reflecting the E2E test configuration changes for the Solana gateway program ID.
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Description
localnet.ymlfile.Closes: #3148
How Has This Been Tested?
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes
Refactor
These updates significantly enhance the functionality and reliability of the ZetaChain ecosystem.