feat(zetaclient): process first solana transaction faster#3433
feat(zetaclient): process first solana transaction faster#3433
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the 📝 WalkthroughWalkthroughThe pull request introduces refined logic for processing cross-chain transactions (CCTXs) in the Solana orchestrator. The primary modification involves enhancing the Changes
Possibly related PRs
Suggested Labels
Suggested Reviewers
The modifications represent a nuanced approach to transaction scheduling, providing more flexible and responsive handling of cross-chain transactions within the Solana orchestrator's workflow. Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #3433 +/- ##
===========================================
- Coverage 64.42% 64.40% -0.03%
===========================================
Files 436 436
Lines 30368 30379 +11
===========================================
+ Hits 19565 19566 +1
- Misses 9962 9972 +10
Partials 841 841
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
zetaclient/orchestrator/orchestrator.go (3)
449-450: Consider a more descriptive variable name.Rename
needsProcessingCtrtopendingTransactionCountto better convey its purpose of tracking the number of pending transactions that need processing.- needsProcessingCtr := 0 + pendingTransactionCount := 0
483-491: Fix typo in variable name and approve the immediate processing logic.The logic for immediate processing is well-structured and aligns with the PR objectives. However, there's a typo in the variable name.
- shouldProcessCCTXImmedately := isCCTXNewlyCreated && needsProcessingCtr == 0 + shouldProcessCCTXImmediately := isCCTXNewlyCreated && needsProcessingCtr == 0
498-506: Fix grammar in variable name and approve the scheduling implementation.The scheduling logic effectively combines immediate and interval-based processing, aligning with the PR objectives. However, the variable name needs grammatical improvement.
- shouldScheduledProcess := nonce%interval == zetaHeight%interval + shouldScheduleProcess := nonce%interval == zetaHeight%interval - if shouldProcessCCTXImmedately || shouldScheduledProcess { + if shouldProcessCCTXImmediately || shouldScheduleProcess {
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
zetaclient/orchestrator/orchestrator.go(2 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
zetaclient/orchestrator/orchestrator.go (1)
Pattern **/*.go: Review the Go code, point out issues relative to principles of clean code, expressiveness, and performance.
⏰ Context from checks skipped due to timeout of 90000ms (3)
- GitHub Check: start-e2e-test / e2e
- GitHub Check: start-e2e-performance-test / e2e
- GitHub Check: build-and-test
🔇 Additional comments (1)
zetaclient/orchestrator/orchestrator.go (1)
Line range hint
449-506: Approve the optimization implementation.The implementation successfully achieves faster processing of the first Solana transaction while maintaining the existing scheduling interval and TSS spam prevention. The code is well-structured, properly commented, and thread-safe.
|
Curious, why using |
Because if you try to run an old version of zetaclient and this one together they will not agree on when to sign the first transaction. I'm trying to make it clear that I don't think this is safe to backport directly to the release branch without some additional coordination mechanism. |
ecbc773 to
e28320a
Compare
Apply a slight optimization to solana processing so that we initiate the first pending outbound transaction immediately rather than waiting for the
OutboundScheduleInterval.OutboundScheduleIntervalis 15 on testnet and mainnet so we could end up pointlessly waiting around in quite a few cases. And we really can't reduce that parameter since otherwise TSS will be spammed.There should be little to no change in the performance test results in localnet since we set
OutboundScheduleInterval: 2Mark as consensus breaking since this would need to be deployed with coordination on testnet/mainnet to avoid signer desync.
Conflicts with #3438
Summary by CodeRabbit
New Features
Improvements