Relax log-level on processLockedKeys() for tx results - #898
Conversation
WalkthroughChanged a log call in processLockedKeys: when COATxLookupEnabled is true and GetTransactionResultsByBlockID returns a non-canceled error, the log level was downgraded from Error to Warning and the message was simplified to log the error via %v (block ID removed). Control flow unchanged. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
services/requester/keystore/key_store.go(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Lint
- GitHub Check: Test
🔇 Additional comments (1)
services/requester/keystore/key_store.go (1)
214-214: LGTM: Log level change is appropriate.The change from
Err()toWarn()aligns well with the PR objectives. Since this condition can occur transiently when transaction results are requested before the Access Node finishes indexing, treating it as a warning rather than an error reduces unnecessary alert noise while still maintaining visibility.
830b778 to
1fe28b5
Compare
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
services/requester/keystore/key_store.go (1)
214-217: Log level change looks good; consider including block ID for better debugging.The log level change from
ErrortoWarnappropriately reflects that this condition is not critical, as explained in the PR description. The simplified message also resolves the inconsistency flagged in the previous review where the message mentioned "block ID" but logged the error instead.However, for debugging purposes, including both the block ID and error would provide more context when investigating issues. This was the recommended Option 1 in the previous review.
Consider this enhancement:
- k.logger.Warn().Msgf( - "failed to get transaction results: %v", - err, + k.logger.Warn().Err(err).Msgf( + "failed to get transaction results for block ID: %s", + blockHeader.ID.Hex(), )This uses structured logging to attach the error and includes the block ID in the message, making it easier to trace issues back to specific blocks.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
services/requester/keystore/key_store.go(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Test
| if err != nil && status.Code(err) != codes.Canceled { | ||
| k.logger.Error().Err(err).Msgf( | ||
| "failed to get transaction results for block ID: %s", | ||
| blockHeader.ID.Hex(), |
There was a problem hiding this comment.
should we still add this? blockHeader.ID.Hex()
There was a problem hiding this comment.
I did not add it, because it's already included in the error itself:
failed to get transaction results: client: rpc error: code = Internal desc =
failed to get block df6e3694dd5856d4c3c537ca2d4804aeb78fdaeb48679c506e7cd5fca2d3df95:
could not find block with ID df6e3694dd5856d4c3c537ca2d4804aeb78fdaeb48679c506e7cd5fca2d3df951fe28b5 to
3a3895b
Compare
Description
The previous
ERRlog-level, created unnecessary noise on Grafana panels, as this behavior is not really an error. It might happen because we requested the tx results on a given block, too fast, or the AN hasn't finished indexing them. In any case, this is not critical.Changed the log-level to
WARN.For contributor use:
masterbranchFiles changedin the Github PR explorerSummary by CodeRabbit