feat(e2e): add support for TON tests on live networks#3612
feat(e2e): add support for TON tests on live networks#3612
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 📝 WalkthroughWalkthroughThis pull request adds support for TON live end-to-end tests while refactoring TON configuration and client handling across the project. The changes update configuration files, command-line flags, and error messages by replacing legacy parameters (e.g. Changes
Sequence Diagram(s)sequenceDiagram
participant Runner
participant Faucet
participant UserWallet
participant TONNode
Runner->>Faucet: Request faucet details (faucetURL)
Faucet-->>Runner: Return faucet info
Runner->>UserWallet: Provision TON user account (tonProvisionUser)
UserWallet->>TONNode: Deploy wallet and fund account
TONNode-->>UserWallet: Confirm account activation
UserWallet-->>Runner: Return wallet and gateway details
sequenceDiagram
participant Test as E2E Test
participant Runner as E2ERunner
participant Gateway as TON Gateway
participant Client as TON Client
participant Node as TON Node
Test->>Runner: Initiate TONDeposit(gw, sender, amount, recipient)
Runner->>Gateway: Process deposit request
Gateway->>Client: Submit deposit transaction
Client->>Node: Execute deposit on blockchain
Node-->>Client: Confirm transaction
Client-->>Gateway: Return status
Gateway-->>Runner: Relay deposit result
Runner-->>Test: Complete deposit operation
Possibly related PRs
Suggested labels
Suggested reviewers
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:
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
|
ton | 🏃 starting TON tests
ton | ⏳ running - ton_deposit
ton | ✅ completed - ton_deposit (11.0284141s)
ton | ⏳ running - ton_deposit_and_call
ton | ✅ completed - ton_deposit_and_call (9.027551147s)
ton | ⏳ running - ton_deposit_refund
ton | ✅ completed - ton_deposit_refund (21.116649085s)
ton | ⏳ running - ton_withdraw
ton | ✅ completed - ton_withdraw (19.115756779s)
ton | ⏳ running - ton_withdraw_concurrent
ton | ✅ completed - ton_withdraw_concurrent (1m5.278413836s)
ton | 🍾 ton tests completed in 2m5.567447608s |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #3612 +/- ##
===========================================
- Coverage 64.56% 64.51% -0.05%
===========================================
Files 469 469
Lines 32772 32772
===========================================
- Hits 21159 21144 -15
- Misses 10648 10658 +10
- Partials 965 970 +5
🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (18)
e2e/runner/ton/faucet.go (1)
46-53: Clean helper function implementation.The
gethelper function is concise and follows best practices for creating HTTP requests with context. Consider adding a timeout configuration for production environments to prevent hanging requests.func get(ctx context.Context, url string) (*http.Response, error) { + // Create a context with timeout to prevent hanging requests + ctx, cancel := context.WithTimeout(ctx, 10*time.Second) + defer cancel() + req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil) if err != nil { return nil, err } return http.DefaultClient.Do(req) }e2e/e2etests/test_ton_deposit_and_call.go (1)
32-34: Remove TODO comment before merging.The TODO comment referencing the pre-PR code base should be addressed or removed before merging the PR.
- // Ensure zevmauth user has ZETA balance - // todo check pre-PR code base (prev code)cmd/zetae2e/local/local.go (1)
180-183: Code improvement for future maintainabilityThe comment about dropping this condition in the future is helpful. Consider adding a GitHub issue reference to track this technical debt, which would make it easier to find and address later when TON e2e tests are included in the default suite.
e2e/runner/ton/accounts_test.go (1)
15-18: Consider security implications when logging private keysWhile helpful for debugging, logging private keys (even seed-derived ones) could pose a security risk if logs are exposed. Consider using a dedicated test logger with appropriate log levels or redacting part of the key in production environments.
e2e/runner/ton.go (2)
42-46: Consider removing redundant TONGateway check.While the gateway parameter addition enhances flexibility by allowing callers to specify which gateway to use, line 49 still checks
r.TONGatewaydespite no longer using it for the operation. This inconsistency could lead to confusion.func (r *E2ERunner) TONDeposit( gw *toncontracts.Gateway, sender *wallet.Wallet, amount math.Uint, zevmRecipient eth.Address, ) (*cctypes.CrossChainTx, error) { chain := chains.TONLocalnet - require.NotNil(r, r.TONGateway, "TON Gateway is not initialized") + require.NotNil(r, gw, "Gateway parameter is nil") require.NotNil(r, sender, "Sender wallet is nil")Also applies to: 63-63
81-87: Apply the same gateway check improvement to TONDepositAndCall.Similar to the TONDeposit method, this method now uses the gateway parameter but still checks r.TONGateway.
func (r *E2ERunner) TONDepositAndCall( gw *toncontracts.Gateway, sender *wallet.Wallet, amount math.Uint, zevmRecipient eth.Address, callData []byte, opts ...TONOpt, ) (*cctypes.CrossChainTx, error) { cfg := &tonOpts{expectedStatus: cctypes.CctxStatus_OutboundMined} for _, opt := range opts { opt(cfg) } chain := chains.TONLocalnet - require.NotNil(r, r.TONGateway, "TON Gateway is not initialized") + require.NotNil(r, gw, "Gateway parameter is nil")Also applies to: 95-95, 110-110
e2e/runner/ton/client.go (2)
44-69: Parameterize block waiting constants.The method has hard-coded values for blocks to wait (3) and interval (3 seconds) that could be better expressed as parameters or configurable constants to improve flexibility.
-func (c *Client) WaitForBlocks(ctx context.Context) error { +func (c *Client) WaitForBlocks(ctx context.Context, blocksToWait int32, interval time.Duration) error { const ( - blocksToWait = 3 - interval = 3 * time.Second + defaultBlocksToWait = 3 + defaultInterval = 3 * time.Second ) + + if blocksToWait <= 0 { + blocksToWait = defaultBlocksToWait + } + if interval <= 0 { + interval = defaultInterval + }
71-88: Consider making timeout configurable.The current implementation has a fixed timeout (10 attempts with 5-second intervals). Consider adding a parameter for the timeout or maximum attempts to make the function more adaptable to different network conditions.
-func (c *Client) WaitForAccountActivation(ctx context.Context, account ton.AccountID) error { +func (c *Client) WaitForAccountActivation(ctx context.Context, account ton.AccountID, maxAttempts int, interval time.Duration) error { const ( - interval = 5 * time.Second + defaultInterval = 5 * time.Second + defaultMaxAttempts = 10 ) - for i := 0; i < 10; i++ { + if maxAttempts <= 0 { + maxAttempts = defaultMaxAttempts + } + if interval <= 0 { + interval = defaultInterval + } + + for i := 0; i < maxAttempts; i++ {cmd/zetae2e/config/localnet.yml (1)
125-132: Highlight the newly added TON gateway configuration.
This block adds a placeholdergateway_account_id. Make sure downstream code validates and populates this value. Consider robust error handling if left empty.cmd/zetae2e/config/local.yml (1)
148-152: New TON contract configuration block.
This portion forgateway_account_idappears to be a placeholder. Confirm that the integration code checks for empty or invalid IDs.e2e/runner/ton/deployer.go (2)
19-20: Adoption of the new Client struct.
Replacing theblockchaininterface with*Clientcan simplify the code but reduces abstraction. Confirm that this aligns with your broader architecture plans.Also applies to: 23-23, 45-45
79-81: Robust transaction sending and confirmation.
The approach to retrieve and wait for a new seqno ensures higher reliability. The inlined comment about “message hash is not a tx hash” is constructive. Consider adding short in-code references to any official TON documentation or best practices for new contributors.Also applies to: 86-87, 93-93, 98-98
e2e/runner/setup_ton.go (3)
36-45: Minor logging method clarity.Since you are passing multiple arguments to
r.Logger.Print, ensure your custom logger method interprets and formats them correctly. If it does not support this format natively, consider usingPrintfor a similar approach.
65-65: Consider making the deposit amount configurable.Hardcoding
1000 TONmight reduce flexibility under different test scenarios.
67-68: Return value fromtonProvisionUseris ignored.You might wish to capture or verify the returned wallet to confirm successful provisioning.
e2e/config/config.go (3)
65-65: Storing TON private keys in plaintext config may raise security concerns.Consider encrypting or redacting them, especially for non-local/test environments.
203-203: Revisit usage of HTTP for the TON liteserver.If encryption is not critical for local tests, this is acceptable. Otherwise, consider an HTTPS endpoint.
449-460:AsTONWalletusage is concise; ignoring the initialaccInitmay be acceptable if unneeded.If the
accInitdata is useful for logging or future operations, consider storing or emitting it.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (30)
changelog.md(1 hunks)cmd/zetae2e/config/clients.go(3 hunks)cmd/zetae2e/config/config.go(1 hunks)cmd/zetae2e/config/contracts.go(2 hunks)cmd/zetae2e/config/local.yml(3 hunks)cmd/zetae2e/config/localnet.yml(2 hunks)cmd/zetae2e/init.go(1 hunks)cmd/zetae2e/local/local.go(2 hunks)cmd/zetae2e/local/ton.go(1 hunks)cmd/zetae2e/root.go(2 hunks)cmd/zetatool/cctx/inbound_test.go(1 hunks)contrib/localnet/orchestrator/start-zetae2e.sh(1 hunks)contrib/localnet/scripts/start-zetacored.sh(1 hunks)contrib/localnet/scripts/wait-for-ton.sh(1 hunks)e2e/config/config.go(10 hunks)e2e/e2etests/test_ton_deposit.go(1 hunks)e2e/e2etests/test_ton_deposit_and_call.go(1 hunks)e2e/e2etests/test_ton_deposit_refund.go(2 hunks)e2e/e2etests/test_ton_withdrawal.go(3 hunks)e2e/e2etests/test_ton_withdrawal_concurrent.go(1 hunks)e2e/runner/runner.go(5 hunks)e2e/runner/setup_ton.go(5 hunks)e2e/runner/ton.go(4 hunks)e2e/runner/ton/accounts.go(2 hunks)e2e/runner/ton/accounts_test.go(2 hunks)e2e/runner/ton/client.go(1 hunks)e2e/runner/ton/clients.go(0 hunks)e2e/runner/ton/deployer.go(3 hunks)e2e/runner/ton/faucet.go(1 hunks)zetaclient/chains/ton/config/config.go(2 hunks)
💤 Files with no reviewable changes (1)
- e2e/runner/ton/clients.go
🧰 Additional context used
📓 Path-based instructions (2)
`**/*.sh`: Review the shell scripts, point out issues relati...
**/*.sh: Review the shell scripts, point out issues relative to security, performance, and maintainability.
contrib/localnet/scripts/wait-for-ton.shcontrib/localnet/orchestrator/start-zetae2e.shcontrib/localnet/scripts/start-zetacored.sh
`**/*.go`: Review the Go code, point out issues relative to ...
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
cmd/zetae2e/local/ton.goe2e/e2etests/test_ton_deposit_and_call.gocmd/zetae2e/config/contracts.gocmd/zetatool/cctx/inbound_test.gocmd/zetae2e/init.gocmd/zetae2e/config/config.gozetaclient/chains/ton/config/config.goe2e/e2etests/test_ton_withdrawal_concurrent.gocmd/zetae2e/root.goe2e/e2etests/test_ton_deposit.gocmd/zetae2e/local/local.goe2e/runner/ton/accounts_test.goe2e/runner/ton/faucet.goe2e/e2etests/test_ton_deposit_refund.goe2e/e2etests/test_ton_withdrawal.gocmd/zetae2e/config/clients.goe2e/runner/ton/client.goe2e/runner/ton/accounts.goe2e/runner/ton/deployer.goe2e/runner/runner.goe2e/runner/ton.goe2e/runner/setup_ton.goe2e/config/config.go
🪛 GitHub Check: codecov/patch
zetaclient/chains/ton/config/config.go
[warning] 44-44: zetaclient/chains/ton/config/config.go#L44
Added line #L44 was not covered by tests
[warning] 50-50: zetaclient/chains/ton/config/config.go#L50
Added line #L50 was not covered by tests
🪛 Gitleaks (8.21.2)
cmd/zetae2e/config/localnet.yml
40-40: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
41-41: Detected a Generic API Key, potentially exposing access to various services and sensitive operations.
(generic-api-key)
🔇 Additional comments (75)
contrib/localnet/scripts/wait-for-ton.sh (1)
4-4: Improved polling frequency for TON status checks.Reducing the polling interval from 10 to 5 seconds is a good optimization that decreases detection time for TON node readiness while maintaining the same overall timeout of 300 seconds.
changelog.md (1)
50-50: Well-documented TON e2e test support.The changelog entry properly documents the addition of TON live end-to-end tests, which aligns with the code changes observed in this PR.
cmd/zetae2e/config/contracts.go (2)
9-9: Appropriate TON library dependency added.The import of the TON package is necessary for parsing TON account IDs in the contract configuration.
122-124: Proper TON gateway configuration integration.The implementation for configuring the TON gateway follows the same pattern as other blockchain configurations in this file, ensuring consistent behavior across different chains.
contrib/localnet/orchestrator/start-zetae2e.sh (1)
118-120: Added TON account funding similar to other chains.The implementation appropriately extends the account funding process to include TON tester accounts, maintaining consistency with how other blockchain accounts are handled.
cmd/zetae2e/config/config.go (1)
60-60: Good addition for TON gateway integration.The addition of
TONGatewayto the configuration export process follows the established pattern for other blockchain configurations in this codebase.cmd/zetae2e/root.go (2)
9-15: Refactoring variable to constant improves code quality.Converting
asciiArttobanneras a constant is appropriate since the ASCII art is immutable. This change follows best practices for declaring immutable values as constants rather than variables.
20-20: Updated reference to use the new constant name.The reference has been correctly updated to use the new constant name.
cmd/zetatool/cctx/inbound_test.go (2)
11-11: Added import for test conditioning.The addition of the
commonpackage import is necessary for the new test condition.
15-18: Good testing practice: Condition for live tests.Adding a condition to skip tests when live tests are not enabled is a good practice. This prevents test failures in environments where live testing is not available or appropriate.
zetaclient/chains/ton/config/config.go (3)
17-17: Improved error handling with dedicated error variable.Creating a dedicated error variable for download failures improves error handling consistency and makes it easier to check for specific error types in client code.
44-44:Details
❓ Verification inconclusive
Better error wrapping with consistent error type.
The error wrapping has been improved to use the new dedicated error variable, which enhances error consistency.
The static analysis shows this line isn't covered by tests. Consider adding test coverage for this error path:
🏁 Script executed:
#!/bin/bash # Search for tests that cover the error handling in FromURL rg -A 3 -B 3 "TestFromURL|test.*FromURL" --type goLength of output: 52
Action Required: Enhance Test Coverage for Error Handling in FromURL
- The error wrapping in
zetaclient/chains/ton/config/config.go(line 44) now consistently uses the dedicated error variable, which is a positive improvement.- However, static analysis indicates that this error path isn’t covered by any tests. The search for tests related to
FromURLreturned no results.- Please add test cases that simulate the failure conditions triggering
ErrDownloadinFromURLto ensure this branch is properly exercised.🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 44-44: zetaclient/chains/ton/config/config.go#L44
Added line #L44 was not covered by tests
50-50:Details
❓ Verification inconclusive
Consistent error handling for HTTP status errors.
The HTTP status error handling now uses the same dedicated error variable, maintaining consistency in error reporting.
This line also lacks test coverage according to static analysis. Consider ensuring that both error paths are tested:
🏁 Script executed:
#!/bin/bash # Check if there are any tests that simulate HTTP status errors rg -A 5 -B 5 "StatusCode.*!= http\.StatusOK|Mock.*HTTP.*Status" --type goLength of output: 2152
HTTP Status Error Handling and Test Coverage
The error handling in
zetaclient/chains/ton/config/config.gonow correctly wraps non-OK HTTP responses using the dedicatedErrDownloadvariable, ensuring consistency in error reporting. However, static analysis indicates that the error path for non-200 HTTP statuses (at line 50) lacks test coverage. Please verify that tests cover both the scenario where an error message is provided (e.g., usingerr.Error()) and the scenario whereres.Statusis used directly. You might consider adding unit or integration tests similar to those ine2e/runner/ton/faucet.gothat simulate HTTP status errors.🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 50-50: zetaclient/chains/ton/config/config.go#L50
Added line #L50 was not covered by testscmd/zetae2e/init.go (1)
34-34: Updated TON RPC configuration for new architecture.The flag has been renamed from
--tonSidecarURLto--tonURLand the implementation now usesinitConf.RPCs.TONinstead ofinitConf.RPCs.TONSidecarURL, reflecting a shift from a sidecar approach to a more direct TON client integration. The default URL has also been updated to point to a lite-client configuration.contrib/localnet/scripts/start-zetacored.sh (1)
249-251: TON tester account configuration added.The addition follows the established pattern for other blockchain testers, correctly retrieving the Bech32 address from the configuration file and adding it to the genesis with the appropriate balance.
e2e/runner/ton/faucet.go (2)
10-23: Well-structured Faucet implementation.The
Faucetstruct is properly defined with appropriate fields for TON wallet information. The linter suppression comment suggests this interface matches an external API structure (my-local-ton).
25-44: Robust faucet retrieval implementation.The
GetFaucetfunction follows good practices for HTTP requests, including proper context handling, error checking, and response validation.e2e/e2etests/test_ton_deposit_and_call.go (5)
16-20: Simplified context and gateway initialization.The code now uses the runner's context directly and initializes a TON gateway object, which is a cleaner approach than the previous implementation.
25-25: Updated fee retrieval mechanism.The code now uses the gateway object to retrieve transaction fees, which is more consistent with the new TON client architecture.
29-29: Improved wallet acquisition method.Using
r.Account.AsTONWalletcentralizes the wallet creation logic in the account structure, which is a better design than the previous implementation using a deployer.
37-37: Enhanced error message for contract deployment.The error message now clearly indicates what failed ("unable to deploy example contract"), which improves debugging.
44-44: Updated deposit and call method signature.The method now accepts a gateway object instead of a sender directly, which aligns with the new TON integration architecture.
cmd/zetae2e/local/local.go (1)
260-265: Well-structured TON setup implementationThe TON setup implementation follows the same pattern as other blockchain setups in this file (like Solana and Sui), ensuring consistency in the codebase. The conditional check ensures the setup only runs when needed.
cmd/zetae2e/local/ton.go (1)
26-26: Appropriate account reference for TON testsSwitching from the generic
DefaultAccountto the TON-specificUserTONaccount is appropriate and improves code clarity. This change aligns with the architectural pattern of using chain-specific accounts for specialized tests.e2e/e2etests/test_ton_withdrawal_concurrent.go (1)
64-64: Simplified balance retrievalDirect use of
r.Clients.TON.GetBalanceOfeliminates an unnecessary abstraction layer, resulting in cleaner and more maintainable code. This change also improves consistency with other test implementations.e2e/runner/ton/accounts_test.go (1)
21-21: Improved wallet construction approachSwitching to
ConstructWalletFromPrivateKeyis a good refactoring that aligns with modern cryptographic practices by clearly separating the seed generation and key derivation steps. This approach provides better flexibility for key management.e2e/e2etests/test_ton_deposit_refund.go (4)
9-9: Good addition of the toncontracts import.The import is necessary for using the Gateway functionality and helps organize the code better.
22-24: Clean initialization of the Gateway.Good practice to initialize the gateway separately for better clarity. This follows the single responsibility principle by extracting the gateway creation logic.
31-34: Well-structured wallet acquisition.Using Account.AsTONWallet provides a cleaner way to get a TON wallet, rather than directly referencing the deployer's wallet. The error handling is also properly implemented.
39-41: Cleaner parameter passing.Passing explicitly initialized objects (gw and sender) to TONDepositAndCall improves readability and makes the dependencies clearer compared to direct references.
e2e/e2etests/test_ton_withdrawal.go (4)
20-21: Clean gateway initialization.Good separation of concerns by initializing the gateway explicitly at the beginning of the test.
31-33: Simplified wallet acquisition.Using the Account.AsTONWallet method provides a more direct and cleaner approach to get a TON wallet.
35-38: Consistent variable usage.The code consistently uses the new receiver variable. Make sure all other references are also updated, including logging statements.
80-81: Clean gateway AccountID usage.Using gw.AccountID() to access the gateway's account ID is more maintainable than directly accessing the internal structure.
e2e/e2etests/test_ton_deposit.go (5)
16-17: Explicit context assignment improves clarity.Good practice to explicitly assign the context at the beginning of the function for better readability and consistency.
18-19: Clean gateway initialization.The explicit gateway initialization improves code organization and follows the single responsibility principle.
25-26: Improved fee retrieval approach.Using the gateway's GetTxFee method directly with the context and operation type is cleaner and more maintainable.
29-30: Better wallet acquisition.Using Account.AsTONWallet is a more direct approach for obtaining a TON wallet, improving code clarity.
36-37: Simplified parameter passing.Passing the gateway and sender objects explicitly to TONDeposit makes the dependencies clearer and improves maintainability.
cmd/zetae2e/config/clients.go (4)
47-49: Updated conditional for TON client initialization.The condition now checks for TON configuration instead of TONSidecarURL, which is more appropriate for the new approach.
135-139: Improved function signature and error messaging.Renamed parameter from sidecarURL to configURLOrPath better reflects its purpose. The error message is also updated to be more accurate.
144-145: Simplified TON configuration retrieval.Using tonconfig.FromSource directly improves code readability by removing the unnecessary sidecar client intermediary.
157-158: Streamlined client return structure.The simplified return statement only includes the Client field, which is cleaner and aligns with the removal of the sidecar dependency.
e2e/runner/ton.go (1)
37-37: Excellent code simplification.The refactored function elegantly condenses the implementation into a single line, improving readability while preserving functionality.
e2e/runner/ton/accounts.go (4)
28-39: Clean implementation of PrivateKeyFromHex function.The function properly handles hex string decoding with appropriate error handling and validation of the private key length.
43-46: Good defensive check for empty seed.Adding validation for empty seed strings prevents cryptic errors that might occur later in the function execution.
50-50: Improved error handling with formatted message.Using
errors.Wrapfinstead oferrors.Wrapprovides better context in error messages by including formatted information.
43-43: Enhanced type safety with specific client parameter.Changing from
blockchainto*Clientincreases type safety and makes the function's requirements more explicit.Also applies to: 56-56
e2e/runner/runner.go (3)
118-119: Good TON integration with appropriate type.Using
ton.AccountIDfor the TONGateway field aligns with the SDK's type system.
404-409: Well-structured TON address display.The implementation properly handles both the case when the TONGateway is set and when it's not, providing clear feedback to users.
466-468: Enhanced error context in FailNow.Including the runner name in the error message improves debugging by providing more contextual information about which runner failed.
Also applies to: 470-470
e2e/runner/ton/client.go (3)
15-17: Effective composition with embedded struct.Embedding
*liteapi.Clientis a clean way to extend functionality while maintaining access to the underlying client methods.
25-42: Well-implemented balance retrieval with activation waiting.The method correctly implements the option to wait for account activation before checking balance and provides clear error messages.
90-110: Effective polling with timeout.The
WaitForNextSeqnomethod efficiently implements a timeout-based polling mechanism with appropriate error handling.cmd/zetae2e/config/localnet.yml (1)
116-118: Clarify or validate the TON configuration endpoints.
The newton_liteserver_configandton_faucetfields point to JSON files. Ensure these paths or URLs are valid and properly secured.cmd/zetae2e/config/local.yml (1)
120-121: Validate or secure the newly introduced TON endpoints.
Ensure these URLs are correct, handle credential injection, and have robust fallback or error handling.e2e/runner/ton/deployer.go (1)
65-66: Deploy method enhancements.
UsingMode: toncontracts.SendFlagSeparateFeesclarifies that fees are kept separate. The additional error context in line 69 aids debugging. Furthermore,WaitForAccountActivationin line 72 is a clear improvement for verifying deployment success.Also applies to: 69-69, 72-72
e2e/runner/setup_ton.go (11)
4-4: No major issues identified with the newly added imports.Also applies to: 7-7, 9-10, 12-12
30-31: Faucet retrieval logic looks sound.
34-34: Sufficient error checking on TON deployer creation.
48-49: Gateway initialization check is clear and correct.
51-52: Gateway deployment logic appears reliable.
54-57: Verifying the gateway's balance is a good fail-fast approach.
70-72: TON chain params check is properly guarded.
74-74: Depositing TON to the user account is well-structured.Also applies to: 76-83
126-126: Logging statement for chain params approval is straightforward.
135-135: Log statement ensures clarity on TON chain params finalization.
145-172:tonProvisionUserfunction is coherent and aligned with the rest of the flow.Deployment, balance checks, and logging are handled properly.
e2e/config/config.go (7)
15-16: New imports for errors and TON wallet integration appear correct.Also applies to: 19-19
68-68: Documentation comment updated.
78-78: NewUserTONaccount field looks consistent with other user accounts.
109-110: Renamed RPC references for TON are straightforward and clear.
131-131: NewTONstruct for gateway configurations is fitting and consistent with the codebase pattern.Also applies to: 141-145
270-270: Inclusion ofUserTONin the additional accounts slice is logically consistent.
367-370: Key generation forUserTONfollows the standard pattern.
There was a problem hiding this comment.
Actionable comments posted: 3
🔭 Outside diff range comments (2)
e2e/runner/ton.go (2)
40-46: 🛠️ Refactor suggestionRefactor parameter validation for consistency
The method signature has been updated to receive the gateway as a parameter (good design), but the validation still checks
r.TONGatewayinstead of the passed gateway parameter.func (r *E2ERunner) TONDeposit( gw *toncontracts.Gateway, sender *wallet.Wallet, amount math.Uint, zevmRecipient eth.Address, ) (*cctypes.CrossChainTx, error) { chain := chains.TONLocalnet - require.NotNil(r, r.TONGateway, "TON Gateway is not initialized") + require.NotNil(r, gw, "TON Gateway is not initialized") require.NotNil(r, sender, "Sender wallet is nil") require.False(r, amount.IsZero()) require.NotEqual(r, (eth.Address{}).String(), zevmRecipient.String())Also applies to: 49-53
79-87: 🛠️ Refactor suggestionRefactor parameter validation for consistency
Similar to the TONDeposit method, the validation here still checks
r.TONGatewayinstead of the passed gateway parameter.func (r *E2ERunner) TONDepositAndCall( gw *toncontracts.Gateway, sender *wallet.Wallet, amount math.Uint, zevmRecipient eth.Address, callData []byte, opts ...TONOpt, ) (*cctypes.CrossChainTx, error) { cfg := &tonOpts{expectedStatus: cctypes.CctxStatus_OutboundMined} for _, opt := range opts { opt(cfg) } chain := chains.TONLocalnet - require.NotNil(r, r.TONGateway, "TON Gateway is not initialized") + require.NotNil(r, gw, "TON Gateway is not initialized")Also applies to: 95-95
🧹 Nitpick comments (11)
cmd/zetatool/cctx/inbound_test.go (1)
15-19: Well-structured skip condition for live tests.The implementation correctly uses
common.LiveTestEnabled()to determine whether the test should run, following Go testing best practices. This change aligns with the PR objective of adding support for TON tests on live networks.However, consider adding documentation about when
LiveTestEnabled()would return true and how users can enable live tests if needed. This would improve developer experience when they encounter skipped tests.func Test_InboundBallotIdentifier(t *testing.T) { + // Skip this test unless explicitly enabled for live testing + // To enable, set LIVE_TEST=true environment variable if !common.LiveTestEnabled() { t.Skip("skipping live test") return }e2e/runner/ton/faucet.go (2)
25-44: Enhance error handling and add request timeoutThe GetFaucet implementation works but could benefit from improved error handling and a timeout configuration.
// GetFaucet returns the faucet information. func GetFaucet(ctx context.Context, url string) (Faucet, error) { resp, err := get(ctx, url) if err != nil { - return Faucet{}, err + return Faucet{}, fmt.Errorf("failed to get faucet info from %s: %w", url, err) } defer resp.Body.Close() if resp.StatusCode != http.StatusOK { - return Faucet{}, fmt.Errorf("unexpected response status: %d", resp.StatusCode) + return Faucet{}, fmt.Errorf("unexpected response status from %s: %d", url, resp.StatusCode) } var faucet Faucet if err := json.NewDecoder(resp.Body).Decode(&faucet); err != nil { - return Faucet{}, err + return Faucet{}, fmt.Errorf("failed to decode faucet response: %w", err) } return faucet, nil }
46-53: Add timeout to HTTP client and consider a custom clientThe HTTP client implementation should include a timeout to prevent hanging in case of network issues.
func get(ctx context.Context, url string) (*http.Response, error) { req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil) if err != nil { return nil, err } - return http.DefaultClient.Do(req) + client := &http.Client{ + Timeout: 10 * time.Second, + } + return client.Do(req) }Don't forget to add the time import:
import ( "context" "encoding/json" "fmt" "net/http" "time" )cmd/zetae2e/config/clients.go (1)
136-138: Function documentation could be more explicit.While the function name and error message have been updated, the documentation comment could be more explicit about the dual capability of accepting both URLs and file paths.
Consider updating the comment to:
-// getTONClient resolved tonrunner based on lite-server config (path or url) +// getTONClient creates a TON client from a configuration source that can be either a URL or a file pathe2e/runner/ton/client.go (4)
15-17: Consider adding an explicit field instead of embedding.While embedding
*liteapi.Clientis a quick way to inherit methods, an explicit field namedinternalClientor similar may enhance clarity and facilitate mocking or extension in the future.
25-42: Validate account state and guard against potential overflow.
- The code dereferences
state.Account.Account.Storage.Balancewithout explicitly checking for a nil account, which could cause issues ifGetAccountStatereturns an uninitialized state.- Storing the balance in a
uint64may risk overflow under rare extremes when dealing with high balances. Consider using a type that can handle larger values if required by the protocol.Proposed guard check:
if wait { if err := c.WaitForAccountActivation(ctx, id); err != nil { return math.Uint{}, errors.Wrap(err, "failed to wait for account activation") } } + if state.Account == nil { + return math.Uint{}, errors.Errorf("account %q state is nil", id.ToRaw()) + } balance := uint64(state.Account.Account.Storage.Balance.Grams) return math.NewUint(balance), nil
44-69: Introduce a maximum wait threshold.
WaitForBlocksloops until it observes a certain block height, potentially waiting indefinitely.
Consider adding an upper bound on waiting time or tying the loop toctxcancellation to prevent unbounded blocking.
71-88: Parameterized maximum retries.The current 10-iteration approach may not be suitable for all scenarios. Exposing the retry count/interval or making them configurable could improve flexibility.
e2e/runner/ton/deployer.go (1)
75-96: Evaluate block-wait strategy for high-throughput scenarios.While the
sendmethod properly waits for the next seqno and optionally waits for multiple blocks, repeated block waits for frequent transactions may hinder performance if used in tight loops. Considering a configurable or optional approach for block waiting can be beneficial in high-throughput tests.e2e/runner/setup_ton.go (1)
67-68: User account provisioning step is well sequenced.Placing the user account setup after gateway deployment is logical, preventing partial states in the event of earlier failures.
e2e/config/config.go (1)
449-459: TON wallet derivation method implemented.The
AsTONWalletmethod correctly derives a TON wallet from the account's private key with proper error handling. The method documentation also provides an important note to ensure the wallet is deployed on the network.However, consider adding error validation for the
clientparameter to prevent potential nil pointer dereferences.func (a Account) AsTONWallet(client *ton.Client) (*tonwallet.Wallet, error) { + if client == nil { + return nil, errors.New("TON client cannot be nil") + } + pk, err := ton.PrivateKeyFromHex(a.TONPrivateKey.String()) if err != nil { return nil, errors.Wrap(err, "failed to get private key") } _, w, err := ton.ConstructWalletFromPrivateKey(pk, client) return w, err }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (30)
changelog.md(1 hunks)cmd/zetae2e/config/clients.go(3 hunks)cmd/zetae2e/config/config.go(1 hunks)cmd/zetae2e/config/contracts.go(2 hunks)cmd/zetae2e/config/local.yml(3 hunks)cmd/zetae2e/config/localnet.yml(2 hunks)cmd/zetae2e/init.go(1 hunks)cmd/zetae2e/local/local.go(2 hunks)cmd/zetae2e/local/ton.go(1 hunks)cmd/zetae2e/root.go(2 hunks)cmd/zetatool/cctx/inbound_test.go(1 hunks)contrib/localnet/orchestrator/start-zetae2e.sh(1 hunks)contrib/localnet/scripts/start-zetacored.sh(1 hunks)contrib/localnet/scripts/wait-for-ton.sh(1 hunks)e2e/config/config.go(10 hunks)e2e/e2etests/test_ton_deposit.go(1 hunks)e2e/e2etests/test_ton_deposit_and_call.go(1 hunks)e2e/e2etests/test_ton_deposit_refund.go(2 hunks)e2e/e2etests/test_ton_withdrawal.go(3 hunks)e2e/e2etests/test_ton_withdrawal_concurrent.go(1 hunks)e2e/runner/runner.go(5 hunks)e2e/runner/setup_ton.go(5 hunks)e2e/runner/ton.go(4 hunks)e2e/runner/ton/accounts.go(2 hunks)e2e/runner/ton/accounts_test.go(2 hunks)e2e/runner/ton/client.go(1 hunks)e2e/runner/ton/clients.go(0 hunks)e2e/runner/ton/deployer.go(3 hunks)e2e/runner/ton/faucet.go(1 hunks)zetaclient/chains/ton/config/config.go(2 hunks)
💤 Files with no reviewable changes (1)
- e2e/runner/ton/clients.go
🧰 Additional context used
📓 Path-based instructions (2)
`**/*.sh`: Review the shell scripts, point out issues relati...
**/*.sh: Review the shell scripts, point out issues relative to security, performance, and maintainability.
contrib/localnet/orchestrator/start-zetae2e.shcontrib/localnet/scripts/start-zetacored.shcontrib/localnet/scripts/wait-for-ton.sh
`**/*.go`: Review the Go code, point out issues relative to ...
**/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
cmd/zetae2e/config/contracts.gozetaclient/chains/ton/config/config.goe2e/e2etests/test_ton_withdrawal_concurrent.gocmd/zetae2e/root.goe2e/runner/ton/accounts_test.gocmd/zetatool/cctx/inbound_test.goe2e/e2etests/test_ton_deposit_and_call.gocmd/zetae2e/local/ton.gocmd/zetae2e/config/config.goe2e/e2etests/test_ton_deposit_refund.gocmd/zetae2e/local/local.gocmd/zetae2e/config/clients.goe2e/e2etests/test_ton_deposit.goe2e/runner/ton/accounts.goe2e/runner/ton.goe2e/e2etests/test_ton_withdrawal.goe2e/runner/ton/faucet.gocmd/zetae2e/init.goe2e/runner/ton/deployer.goe2e/runner/setup_ton.goe2e/runner/ton/client.goe2e/runner/runner.goe2e/config/config.go
🪛 GitHub Check: codecov/patch
zetaclient/chains/ton/config/config.go
[warning] 44-44: zetaclient/chains/ton/config/config.go#L44
Added line #L44 was not covered by tests
[warning] 50-50: zetaclient/chains/ton/config/config.go#L50
Added line #L50 was not covered by tests
🔇 Additional comments (73)
cmd/zetatool/cctx/inbound_test.go (1)
11-11: Appropriate new import for live test functionality.The addition of the common package import is necessary to support the new live test conditional check.
contrib/localnet/scripts/wait-for-ton.sh (1)
4-4: Improved polling frequency for TON node status check.Reducing the polling interval from 10 seconds to 5 seconds results in more responsive detection of TON node readiness, potentially reducing the overall waiting time during local development and testing.
changelog.md (1)
50-50: Properly documented TON live e2e tests addition.The changelog entry correctly references the pull request and provides a clear, concise description of the feature addition. This follows the established pattern for changelog entries in the project.
contrib/localnet/orchestrator/start-zetae2e.sh (1)
118-120: Added TON tester account funding.This addition follows the established pattern for funding test accounts in the orchestration script. The code properly utilizes the existing
fund_eth_from_configfunction to provide ETH to TON tester accounts, maintaining consistency with other blockchain tester implementations.cmd/zetae2e/config/config.go (1)
60-61: Added TON Gateway Account ID export.The implementation correctly exports the TON Gateway Account ID from the runner to the configuration, following the established pattern for other blockchain configurations. This addition is necessary to support the TON live e2e tests referenced in the changelog.
contrib/localnet/scripts/start-zetacored.sh (1)
249-251: Account initialization for TON tester follows established pattern.The implementation correctly follows the same pattern used for other blockchain testers, ensuring consistency in the initialization process.
cmd/zetae2e/config/contracts.go (1)
122-124: TON Gateway integration properly follows existing patterns.The implementation correctly checks for the TON Gateway Account ID and integrates it into the runner using
ton.MustParseAccountID, which is consistent with how other blockchain configurations are handled in this file.cmd/zetae2e/root.go (1)
9-15: Improved semantics by usingconstfor unchanging banner text.Changing from
vartoconstfor the ASCII art banner is a small but appropriate improvement since this text is static and won't change at runtime.Also applies to: 20-20
e2e/e2etests/test_ton_withdrawal_concurrent.go (1)
64-64: Improved code by removing the intermediate deployer object.The direct usage of
r.Clients.TON.GetBalanceOfsimplifies the code while maintaining the same functionality. This change aligns with the overall refactoring approach in this PR, making the balance retrieval process more straightforward.cmd/zetae2e/local/ton.go (1)
26-26: Enhanced test configuration with TON-specific account.Using
conf.AdditionalAccounts.UserTONinstead of the genericconf.DefaultAccountimproves the test configuration specificity for TON tests, which is essential for live network testing. This change aligns with the PR's objective of supporting TON tests on live networks.e2e/e2etests/test_ton_deposit_and_call.go (5)
18-19: Enhanced code structure with gateway pattern.Introducing a dedicated gateway object with
toncontracts.NewGateway(r.TONGateway)improves encapsulation and follows a consistent pattern for TON operations. This makes the code more maintainable and aligns with the refactoring approach across the codebase.
25-26: Improved fee retrieval through gateway abstraction.Using the gateway to retrieve transaction fees (
gw.GetTxFee) provides a cleaner abstraction and centralizes TON-related operations through the gateway interface. This is a good architectural decision.
28-30: Enhanced wallet instantiation.Using
r.Account.AsTONWallet(r.Clients.TON)provides a cleaner way to create a TON wallet from the account. This is more explicit about the conversion process and dependency on the TON client.
37-37: Improved error reporting.Adding a descriptive error message to the
require.NoErrorcall enhances debugging by providing context about what operation failed when an error occurs. This is a good practice for test code.
44-44: Updated function call to use gateway pattern.The updated call to
r.TONDepositAndCallwith the gateway as a parameter aligns with the new gateway-based architecture. This ensures consistent TON operations through the gateway interface.cmd/zetae2e/init.go (1)
34-34: Updated TON configuration parameter.The flag has been changed from
--tonSidecarURLto--tonURLwith a new default URL format that points to a specific configuration file (/lite-client.json). This update aligns with the refactoring approach to use direct TON services rather than a sidecar approach.Ensure this change is documented for users who might be using the previous
--tonSidecarURLflag in their workflows or CI/CD pipelines. A clear migration path should be provided to avoid disruption.e2e/runner/ton/accounts_test.go (2)
18-18: Consider security implications of logging sensitive information.While logging the seed and private key is useful for debugging in test environments, it could pose a security risk if these logs persist in CI/CD environments or if tests are run against production-like environments.
Consider adding a conditional logging mechanism that only logs this sensitive information when a debug flag is explicitly enabled:
- t.Logf("seed[ %s ] ==> privateKey(0x%s)", seed, hex.EncodeToString(pk.Seed())) + if os.Getenv("DEBUG_LOGS") == "true" { + t.Logf("seed[ %s ] ==> privateKey(0x%s)", seed, hex.EncodeToString(pk.Seed())) + }
15-21: LGTM: Wallet construction test properly enhanced.The enhancement to test wallet construction directly from a private key rather than only from a seed improves test coverage.
cmd/zetae2e/local/local.go (1)
260-265: LGTM: TON setup implementation is clean.The TON setup implementation conditionally calling
SetupTONwith the appropriate parameters is structured well.e2e/e2etests/test_ton_deposit_refund.go (3)
23-23: LGTM: Clean gateway instantiation.Creating a dedicated gateway variable improves readability and maintainability.
31-33: LGTM: Proper sender wallet instantiation.Clean approach to obtain a sender wallet from the account context, with appropriate error handling.
39-40: LGTM: Updated function parameters for consistency.The TONDepositAndCall function now uses the newly created gateway and sender variables, providing a more consistent approach across tests.
e2e/e2etests/test_ton_withdrawal.go (4)
20-21: LGTM: Consistent gateway instantiation.Creating a dedicated gateway variable follows the same pattern used in other tests, improving consistency across the codebase.
31-32: LGTM: Simplified receiver wallet initialization.Directly retrieving the receiver wallet from the account context simplifies the code and reduces dependencies.
45-45: LGTM: Updated function parameters for consistency.Updated withdrawal function call to use the new receiver address, maintaining code consistency.
80-80: LGTM: Using gateway accountID consistently.Using
gw.AccountID()is consistent with the gateway object instantiation pattern established earlier.cmd/zetae2e/config/local.yml (3)
39-43: TON user account configuration looks goodThe added
user_tonaccount follows the established pattern of other blockchain accounts, maintaining consistency in configuration structure.
120-121: Appropriate configuration for TON connectivityThe new TON-specific RPC endpoint configuration entries replace the older TON sidecar URL approach, providing a clearer separation of concerns between the liteserver configuration and faucet services.
149-152: Well-documented TON gateway configurationThe gateway_account_id configuration includes helpful comments explaining why it's initially empty and noting its dynamic nature (unique per e2e test and partially derived from TSS address).
e2e/runner/ton.go (3)
37-37: Good code simplificationThe function has been refactored to a more concise single-line implementation, improving readability.
63-63: Good implementation of dependency injectionUsing the injected gateway instance instead of the runner's gateway instance improves testability and makes dependencies explicit.
110-110: Good implementation of dependency injectionUsing the injected gateway instance improves testability and makes dependencies explicit.
cmd/zetae2e/config/localnet.yml (3)
37-43: TON user account configuration looks goodThe added
user_tonaccount maintains consistency with the local.yml configuration, ensuring a uniform approach across environments.
116-118: Clear TON RPC configuration with helpful commentsThe configuration includes descriptive comments and provides both liteserver and faucet endpoints for the TON blockchain integration.
129-132: Well-documented TON gateway configurationThe gateway_account_id configuration includes helpful comments explaining its dynamic nature, consistent with the approach in local.yml.
e2e/runner/ton/faucet.go (1)
10-23: Well-structured Faucet struct with appropriate JSON tagsThe Faucet struct is well-defined with clear field names and proper JSON tags for serialization/deserialization.
e2e/e2etests/test_ton_deposit.go (4)
16-19: Good refactoring to use the gateway pattern.The change from using a deployer to a gateway instance improves the architecture by centralizing TON interaction logic. This is consistent with the broader refactoring across the codebase.
25-25: Consistent method call update.Correctly updated the GetTxFee call to use the new gateway instance, maintaining the same functionality while aligning with the new architecture.
28-29: Enhanced wallet creation approach.Using
AsTONWalletfrom the account directly is a better abstraction than the previous deployer-based approach. This simplifies the code and reduces dependencies.
36-36: Properly updated function call signature.The signature change to include the gateway as the first parameter ensures consistency with the new gateway-based architecture throughout the codebase.
e2e/runner/ton/accounts.go (4)
28-39: Well-implemented utility function for private key handling.The
PrivateKeyFromHexfunction properly handles hex decoding with appropriate error checking. The validation of key length is particularly important for security.
43-46: Good validation improvement.Adding the empty seed check prevents silent failures and provides clearer error messages. This is a valuable defensive programming practice.
50-50: Enhanced error reporting.Using
errors.Wrapfinstead of justerrors.Wrapprovides more context in the error message, which will help with debugging.
56-56: Type safety improvement.Changing the parameter type from
blockchainto*Clientis a good practice that increases type safety and makes the function's requirements more explicit.cmd/zetae2e/config/clients.go (3)
47-48: Consistent configuration parameter usage.The change from
TONSidecarURLtoTONreflects the more flexible approach being adopted across the codebase, allowing for different configuration sources.
144-144: Simplified client initialization.The direct call to
tonconfig.FromSourceis a cleaner approach that eliminates the need for the intermediate sidecar client, reducing complexity.
157-157: Streamlined return statement.The simplified return statement is cleaner and more maintainable, returning just the client without additional objects.
e2e/runner/runner.go (4)
118-119: Simplified TON-related fields.Consolidating multiple TON-related fields into a single field of a specific type (
ton.AccountID) is a good architectural improvement that reduces complexity.
277-277: Correctly updated address copying.The
CopyAddressesFrommethod has been appropriately updated to handle the new field structure, ensuring consistent behavior.
404-409: Well-structured logging for TON gateway.The addition of TON gateway address logging includes proper null checks and provides clear status information, which helps with debugging and monitoring.
466-469: Improved error messaging.Including the runner's name in the error message provides valuable context that will help with debugging in multi-runner scenarios.
e2e/runner/ton/client.go (2)
19-23: Functionality seems straightforward.
TheStatusmethod succinctly checks the TON node’s health. This is approved as is.
90-110: Reads well and aligns with typical polling patterns.The
WaitForNextSeqnomethod effectively polls until the specified timeout. The approach is coherent and the code is readable.e2e/runner/ton/deployer.go (2)
19-19: Field addition for TON client is clear.Attaching the
*Clientdirectly toDeployersimplifies usage, eliminating the need for an interface. This looks good.
23-45: Constructor logic is solid.
NewDeployercorrectly validates wallet version and work chain, and returns a properly constructed deployer. Error handling is appropriately placed.e2e/runner/setup_ton.go (8)
23-25: Using testify’srequire.*in a setup function.Relying on
requirefor immediate failures is acceptable in an end-to-end test runner. Just be aware that partial actions won't be cleaned up if a requirement fails mid-setup.
30-31: Faucet config retrieval.Fetching the faucet configuration appears straightforward, and
require.NoErrorensures a rapid fail if unavailable. This is suitable for e2e.
33-45: Deployer creation and balance retrieval.The approach of retrieving Deployer balance for logging is sound. The added logs help track test progress.
48-57: Gateway deployment flow.The deployment of the gateway and quick verification of its balance is a robust approach. The added requirement checks ensure fail-fast on unexpected states.
70-72: Updating chain params.Ensuring the chain parameters are set right after gateway deployment clarifies the order of operations, reducing potential side effects.
76-82: Validated deposit checks.Depositing TON into the user account and verifying cctx status ensures the deposit logic is tested end-to-end. The fail-fast pattern with
requireis apt.
83-85: Settingr.TONGateway.Storing the gateway for subsequent tests is a neat approach, enabling direct references later in the suite.
145-172:tonProvisionUsermethod is logically consistent.The method:
- Derives a private key.
- Constructs a wallet and deploys it.
- Retrieves and logs the balance.
This pattern is concise, letting e2e tests quickly provision a TON user account.
e2e/config/config.go (10)
15-16: Dependencies have been correctly added.The new imports for
github.com/pkg/errorsandtonwallet "github.com/tonkeeper/tongo/wallet"are appropriate for handling errors and TON wallet functionality.
19-19: Import follows project structure.The internal TON runner package has been correctly imported to support the TON wallet derivation functionality.
65-65: Account struct extended appropriately.The
TONPrivateKeyfield has been added to theAccountstruct to store the private key for TON accounts, maintaining consistency with other blockchain implementations in the codebase.
78-78: UserTON account added to AdditionalAccounts struct.This enables configuration of a TON user account, consistent with other blockchain user accounts in the system.
109-110: RPC endpoints renamed for clarity.The TON RPCs have been appropriately renamed from
TONSidecarURLto more specificTONfor liteserver config andTONFaucetfor the faucet URL, improving the configuration clarity.
131-131: TON contracts added to Contracts struct.The
TONfield has been correctly added to theContractsstruct to support TON-specific contract configurations.
141-144: TON struct properly defined.The
TONstruct with theGatewayAccountIDfield follows the pattern used for other blockchain configurations in the codebase.
203-203: Default TON configuration added.The
DefaultConfigfunction now correctly initializes the TON liteserver URL, ensuring the configuration is complete for development environments.
270-270: UserTON added to account slice.The
UserTONaccount has been correctly incorporated into theAsSlicemethod, ensuring it's included in operations that process all accounts.
367-370: Key generation for UserTON implemented.The
GenerateKeysmethod now properly generates keys for theUserTONaccount, maintaining consistency with other account types.
gartnera
force-pushed
the
feat/ton/e2e-testnet
branch
from
89c8755 to
3a75015
Compare
swift1337
force-pushed
the
feat/ton/e2e-testnet
branch
from
d2b49ca to
c50065c
Compare
swift1337
force-pushed
the
feat/ton/e2e-testnet
branch
from
c50065c to
4e97dde
Compare
3 participants
This PR decouples TON e2e logic from localnet and allows to run tests on live networks such as testnet 🤞
account.AsTONWalletCloses #3596
Summary by CodeRabbit
New Features
Configuration & Improvements
Tests