feat(ton): lite-server connection tweaks#3697
Conversation
📝 WalkthroughWalkthroughThe changes update the dependency version in the project and modify the client instantiation logic for TON lite API communication. In the Changes
Sequence Diagram(s)sequenceDiagram
participant C as Caller
participant NS as NewFromSource
participant L as liteapi.NewClient
C->>NS: Invoke NewFromSource(ctx, urlOrPath)
NS->>L: Call liteapi.NewClient with dynamic parameters:
note right of NS: - MaxConnectionsNumber based on cfg.LiteServers\n- WorkersPerConnection set to 8
L-->>NS: Return instantiated client
NS-->>C: Return client instance
✨ Finishing Touches
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
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #3697 +/- ##
===========================================
- Coverage 64.59% 64.58% -0.01%
===========================================
Files 469 469
Lines 32911 32915 +4
===========================================
Hits 21259 21259
- Misses 10687 10691 +4
Partials 965 965
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
zetaclient/chains/ton/liteapi/client.go (1)
40-62: 🛠️ Refactor suggestionAdd unit tests for the new connection configuration.
The static analysis shows that the new connection configuration code isn't covered by tests. Consider adding unit tests that verify the client is created with the expected number of connections and workers, especially since this is now dynamically calculated based on configuration.
// NewFromSource creates a new client from a URL or a file path. func NewFromSource(ctx context.Context, urlOrPath string) (*Client, error) { cfg, err := config.FromSource(ctx, urlOrPath) if err != nil { return nil, errors.Wrap(err, "unable to get config") } // most likely, cfg would contain a single lite server (or a small group) // thus we want several connection per lite-server to speed up the requests const workers = 8 client, err := liteapi.NewClient( liteapi.WithConfigurationFile(*cfg), liteapi.WithMaxConnectionsNumber(len(cfg.LiteServers)), liteapi.WithWorkersPerConnection(workers), ) if err != nil { return nil, errors.Wrap(err, "unable to create client") } return New(client), nil }You should add a test similar to:
func TestNewFromSource(t *testing.T) { // Setup mock context and config ctx := context.Background() mockCfg := &config.Config{ LiteServers: []config.LiteServer{ {/* server details */}, {/* server details */}, }, } // Mock the config.FromSource function origFromSource := config.FromSource config.FromSource = func(ctx context.Context, urlOrPath string) (*config.Config, error) { return mockCfg, nil } defer func() { config.FromSource = origFromSource }() // Create a mock for liteapi.NewClient to verify the parameters var capturedMaxConn, capturedWorkers int origNewClient := liteapi.NewClient liteapi.NewClient = func(opts ...liteapi.ClientOption) (*liteapi.Client, error) { // Extract and verify the parameters from the options // This would require additional test infrastructure to inspect the options capturedMaxConn = len(mockCfg.LiteServers) capturedWorkers = 8 return &liteapi.Client{}, nil } defer func() { liteapi.NewClient = origNewClient }() // Call the function client, err := NewFromSource(ctx, "test-path") // Verify results assert.NoError(t, err) assert.NotNil(t, client) assert.Equal(t, len(mockCfg.LiteServers), capturedMaxConn) assert.Equal(t, 8, capturedWorkers) }🧰 Tools
🪛 GitHub Check: codecov/patch
[warning] 49-50: zetaclient/chains/ton/liteapi/client.go#L49-L50
Added lines #L49 - L50 were not covered by tests
[warning] 53-54: zetaclient/chains/ton/liteapi/client.go#L53-L54
Added lines #L53 - L54 were not covered by tests
[warning] 56-56: zetaclient/chains/ton/liteapi/client.go#L56
Added line #L56 was not covered by tests
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
go.sumis excluded by!**/*.sum
📒 Files selected for processing (2)
go.mod(1 hunks)zetaclient/chains/ton/liteapi/client.go(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
`**/*.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.
zetaclient/chains/ton/liteapi/client.go
🪛 GitHub Check: codecov/patch
zetaclient/chains/ton/liteapi/client.go
[warning] 49-50: zetaclient/chains/ton/liteapi/client.go#L49-L50
Added lines #L49 - L50 were not covered by tests
[warning] 53-54: zetaclient/chains/ton/liteapi/client.go#L53-L54
Added lines #L53 - L54 were not covered by tests
[warning] 56-56: zetaclient/chains/ton/liteapi/client.go#L56
Added line #L56 was not covered by tests
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: start-ton-test / e2e
- GitHub Check: start-e2e-test / e2e
🔇 Additional comments (1)
go.mod (1)
313-313:Details
❓ Verification inconclusive
Verify compatibility with the significant tongo library version upgrade.
The update from an unspecified version to v1.14.8 of the
github.com/tonkeeper/tongodependency represents a substantial version jump. This update likely supports the connection configuration changes in the client code, but may introduce API changes or deprecations that should be carefully validated.
🏁 Script executed:
#!/bin/bash # Check the changelog or release notes for the tongo library to understand what changed # between the previous version and v1.14.8 # First, find the previous version that was being used grep -A 2 "github.com/tonkeeper/tongo" go.mod.bak 2>/dev/null || echo "Previous version not found in backup" # Look for GitHub release notes or changelog curl -s "https://api.github.com/repos/tonkeeper/tongo/releases" | grep -m 5 "tag_name\|body" | sed 's/"tag_name":/\nVersion:/g' | sed 's/"body":/\nChanges:/g' | sed 's/\\r\\n/\n/g'Length of output: 397
Compatibility Verification Required for tongo v1.14.8 Upgrade
After reviewing the updated dependency and our investigation:
- The previous version could not be retrieved from the backup, and the GitHub releases endpoint shows older versions (e.g., v1.9.3 and v1.1.1) with no detailed change logs.
- There is no clear changelog or documented migration guide directly addressing the jump to v1.14.8.
- Given the significant version upgrade, it is advisable to manually verify that the new API methods and connection configuration changes in the client code are fully compatible.
Action Items:
- Confirm via the upstream repository or commit history for any breaking API changes introduced in v1.14.8.
- Validate that all uses of the tongo library within the client have been adjusted if necessary.
- Strengthen the test coverage around the connection configuration to catch any subtle incompatibilities.
Related: #2810
Summary by CodeRabbit
Chores
New Features