Update the logging in indexer block processing #6641
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThe pull request introduces modifications to the Changes
Suggested labels
Suggested reviewers
Warning Rate limit exceeded@Teebor-Choka has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 13 minutes and 51 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
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
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Outside diff range and nitpick comments (2)
chain/indexer/src/block.rs (2)
Line range hint
211-229: Consider enhancing error context in logs.While the structured logging is good, consider adding more context about the failed operation (e.g., operation type, affected entities) to aid in debugging.
-error!(%block, error = %err, "Failed to store logs"); +error!(%block, error = %err, operation = "store_logs", "Failed to store logs: database operation failed");
Line range hint
455-472: Extract progress calculation into a separate function.The progress calculation logic could be extracted for better maintainability and testability.
+fn calculate_sync_progress(current_block: u64, next_block: u64, head: u64) -> f64 { + let block_difference = head.saturating_sub(next_block); + if block_difference == 0 { + 1_f64 + } else { + (current_block - next_block) as f64 / block_difference as f64 + } +} if !is_synced.load(Ordering::Relaxed) { - let block_difference = head.saturating_sub(next_block_to_process); - let progress = if block_difference == 0 { - 1_f64 - } else { - (current_block - next_block_to_process) as f64 / block_difference as f64 - }; + let progress = calculate_sync_progress(current_block, next_block_to_process, head);
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
chain/indexer/src/block.rs(10 hunks)
🔇 Additional comments (2)
chain/indexer/src/block.rs (2)
172-174: LGTM! Structured logging implementation.
The logging statement effectively uses structured fields for better observability.
Line range hint 489-750: LGTM! Comprehensive test coverage.
The test suite is well-structured with:
- Good coverage of error cases
- Appropriate use of mocks
- Clear test scenarios
f527959 to
ff15fe9
Compare
ff15fe9 to
29efc3e
Compare
The logging was confusing, redundant in
infolevel and used dynamic data in log messages, not fields. Ths PR fixes that in order to improve the log output.