Skip to content

Conversation

@sundayonah
Copy link
Collaborator

@sundayonah sundayonah commented Dec 20, 2025

Description

Describe the purpose of this PR along with any background information and the impacts of the proposed change. For the benefit of the community, please do not assume prior context.

Provide details that support your chosen implementation, including: breaking changes, alternatives considered, changes to the API, contracts etc.

References

Include any links supporting this change such as a:

If there are no references, simply delete this section.

Testing

Describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. If this project has unit and/or integration testing, tests should be added for new functionality and existing tests should complete without errors.

Please include any manual steps for testing end-to-end or functionality not covered by unit/integration tests.

Also include details of the environment this PR was developed in (language/platform/browser version).

  • This change adds test coverage for new/changed/fixed functionality

Checklist

  • I have added documentation and tests for new/changed functionality in this PR
  • All active GitHub checks for tests, formatting, and security are passing
  • The correct base branch is being used, if not main

By submitting a PR, I agree to Paycrest's Contributor Code of Conduct and Contribution Guide.

Summary by CodeRabbit

  • Chores
    • Enhanced logging and error reporting for transfer event processing: clearer detection/reporting of missing or invalid fields (addresses, values, block/transaction identifiers), preprocessing indicators, and parse-failure messages.
    • Improved traceability when transfers are skipped and stronger visibility when transfer handling is invoked to aid troubleshooting and data quality monitoring.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 20, 2025

Walkthrough

Added structured logging around extraction and validation of StarkNet transfer event fields and wired construction of a transferEvent to invoke the existing ProcessTransfers flow; no public API changes.

Changes

Cohort / File(s) Summary
Transfer event processing & logging
services/indexer/starknet.go
Added detailed logging for missing/invalid decoded, non_indexed_params, block_number, transaction_hash, from, to, and value fields; logs for address extraction/normalization, gateway-address checks, skipped transfers, parsing errors; constructed a transferEvent and invoked the existing ProcessTransfers flow.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

  • Review services/indexer/starknet.go for correct logging levels and contexts.
  • Verify nil/empty checks to avoid new nil dereferences.
  • Confirm address-normalization and gateway-address comparison remain correct with added logs.

Possibly related PRs

Suggested reviewers

  • chibie
  • 5ran6

Poem

🐰
I hopped through logs with tiny feet,
I sniffed each transfer, clean and neat,
If fields were missing, I left a note,
Now every hop has clearer scope. 🥕

Pre-merge checks and finishing touches

❌ Failed checks (3 warnings)
Check name Status Explanation Resolution
Description check ⚠️ Warning The PR description is entirely templated with no actual content filled in - all sections remain as placeholder text with no description, references, testing details, or checklist items completed. Fill in the Description section with purpose and impacts, add References linking to issue #407, provide Testing steps with environment details, and check off completed checklist items.
Linked Issues check ⚠️ Warning The PR changes indexing/logging logic in starknet.go but issue #407 requires implementing previous rate queue functionality in CreatePriorityQueueForBucket and AssignLockPaymentOrder functions - no rate-queue related code changes are present. Implement the required changes: modify CreatePriorityQueueForBucket to save previous queues with _prev suffix and update AssignLockPaymentOrder to check both current and previous rates for matches.
Out of Scope Changes check ⚠️ Warning The PR adds logging to starknet.go transfer event handling which appears out of scope relative to issue #407 requirements focused on priority queue rate management across different functions. Either focus on implementing issue #407's priority queue logic changes or clarify in the PR description how logging changes support the rate queue failure reduction objective.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title describes updating indexing logic for Starknet and Voyager services, which aligns with the raw summary showing changes to starknet.go indexing logic, though it lacks specificity about logging additions.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch chores/internallogs

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (2)
services/indexer/starknet.go (2)

251-255: Refactor: Reduce redundant parameter logging.

These extracted parameters are logged again at lines 274-278 (same three fields) and comprehensively at lines 314-323. This creates excessive log volume where the same values appear 2-3 times per transfer event.

Consider removing this log statement and relying on the more comprehensive logging at lines 314-323, or consolidate all parameter logging into a single location.


274-278: Refactor: Remove redundant logging.

This log duplicates the parameter logging at lines 251-255 and is superseded by the comprehensive logging at lines 314-323. This redundancy will create excessive log volume.

🔎 Proposed fix to remove redundant log
-		logger.WithFields(logger.Fields{
-			"valueStr": valueStr,
-			"fromStr":  fromStr,
-			"toStr":    toStr,
-		}).Infof("Processing transfer event details")
-
 		// Parse transfer value
📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 70b57fa and 6f079c7.

📒 Files selected for processing (1)
  • services/indexer/starknet.go (5 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
services/indexer/starknet.go (3)
utils/logger/logger.go (3)
  • WithFields (76-109)
  • Fields (73-73)
  • Infof (125-130)
utils/crypto/crypto.go (1)
  • NormalizeStarknetAddress (312-324)
ent/network/where.go (1)
  • GatewayContractAddress (85-87)
⏰ 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: build-and-test
🔇 Additional comments (7)
services/indexer/starknet.go (7)

202-202: LGTM: Appropriate error logging for malformed events.

These error logs help surface malformed transfer events early in the processing pipeline, improving debuggability.

Also applies to: 207-207


220-220: LGTM: Comprehensive parameter validation logging.

These error logs catch empty parameters after type validation, ensuring robust detection of invalid transfer events.

Also applies to: 232-232, 248-248


259-262: LGTM: Useful filtering transparency.

This informational log provides clear visibility into address-based filtering decisions, which aids in debugging missed transfers.


268-271: LGTM: Clear gateway filtering observability.

This log statement makes the gateway contract filtering logic transparent and aids in debugging the transfer processing flow.


290-290: LGTM: Essential metadata validation logging.

These error logs appropriately flag missing required event metadata (block number and transaction hash).

Also applies to: 297-297


338-343: LGTM: Clean helper function for uint64 extraction.

The implementation correctly handles uint64 type assertion and formatting. However, this function is called at lines 490, 500, 823, and 833 (not marked as changed), suggesting these call sites already existed. This raises a question about whether the function was moved from elsewhere or if there's an annotation inconsistency.

Can you confirm whether this function is newly added or relocated from another location? The existing call sites suggest it may have been defined elsewhere previously.


1-50: Critical: PR objectives don't match actual changes.

The PR is linked to issue #407 which requires implementing priority queue logic to save and check previous provider rates in Redis. However, this PR only adds logging statements with no changes to:

  • Priority queue logic (CreatePriorityQueueForBucket)
  • Order assignment (AssignLockPaymentOrder)
  • Redis operations for storing previous rates (_prev suffix)
  • Rate matching logic

Please clarify:

  1. Is this PR incorrectly linked to issue #407?
  2. Is this partial implementation with logic changes coming in a follow-up PR?
  3. Should the PR description and linked issue be updated to reflect that this only adds observability enhancements?

The current state creates confusion about what this PR is intended to accomplish versus what it actually delivers.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
services/indexer/starknet.go (1)

236-260: Performance concern: Excessive Info-level logging in hot path.

These Info-level logs fire for every transfer event processed. In high-throughput scenarios, this will:

  • Generate massive log volumes
  • Degrade indexing performance
  • Make log analysis difficult

Additionally, lines 236-239 and 256-260 are redundant—they log the same fromStr and toStr values twice within a few lines.

Recommendations:

  1. Use Debug level for detailed extraction/validation logs (lines 236-239, 256-260, 264-267, 273-276, 279-283)
  2. Reserve Info level for significant events (e.g., line 328 is appropriate)
  3. Remove redundant logging at lines 236-239 since lines 256-260 already capture all three fields
🔎 Proposed refactor to use appropriate log levels
-		logger.WithFields(logger.Fields{
-			"fromStr": fromStr,
-			"toStr":   toStr,
-		}).Infof("Extracted transfer event addresses")
-
 		var valueStr string
 		if bigIntVal, ok := nonIndexedParams["value"].(*big.Int); ok {
 			valueStr = bigIntVal.String()
 		} else if feltVal, ok := nonIndexedParams["value"].(*felt.Felt); ok {
 			valueStr = feltVal.BigInt(big.NewInt(0)).String()
 		} else if strVal, ok := nonIndexedParams["value"].(string); ok {
 			valueStr = strVal
 		} else {
 			logger.Errorf("Unexpected type for 'value' parameter in transfer event")
 			continue
 		}
 		if valueStr == "" {
 			logger.Errorf("Empty 'value' parameter in transfer event")
 			continue
 		}
 		logger.WithFields(logger.Fields{
 			"fromStr":  fromStr,
 			"toStr":    toStr,
 			"valueStr": valueStr,
-		}).Infof("Extracted transfer event parameters")
+		}).Debugf("Extracted transfer event parameters")

 		// Filter by userAccountAddress - only process transfers to the specified address
 		if userAccountAddress != "" && !strings.EqualFold(cryptoUtils.NormalizeStarknetAddress(toStr), cryptoUtils.NormalizeStarknetAddress(userAccountAddress)) {
 			logger.WithFields(logger.Fields{
 				"toStr": cryptoUtils.NormalizeStarknetAddress(toStr),
 				"userAccountAddress": cryptoUtils.NormalizeStarknetAddress(userAccountAddress),
-			}).Infof("Skipping transfer event - 'to' address does not match user account address")
+			}).Debugf("Skipping transfer event - 'to' address does not match user account address")
 			continue
 		}

 		// Skip if transfer is from gateway contract
 		if strings.EqualFold(cryptoUtils.NormalizeStarknetAddress(fromStr), cryptoUtils.NormalizeStarknetAddress(token.Edges.Network.GatewayContractAddress)) {
 			logger.WithFields(logger.Fields{
 				"fromStr": cryptoUtils.NormalizeStarknetAddress(fromStr),
 				"GatewayContractAddress": cryptoUtils.NormalizeStarknetAddress(token.Edges.Network.GatewayContractAddress),
-			}).Infof("Skipping transfer event - 'from' address is gateway contract")
+			}).Debugf("Skipping transfer event - 'from' address is gateway contract")
 			continue
 		}
-		logger.WithFields(logger.Fields{
-			"valueStr": valueStr,
-			"fromStr":  cryptoUtils.NormalizeStarknetAddress(fromStr),
-			"toStr":    cryptoUtils.NormalizeStarknetAddress(toStr),
-		}).Infof("Processing transfer event details")
🧹 Nitpick comments (1)
services/indexer/starknet.go (1)

202-207: Error logging is appropriate, but could include more context.

The error-level logging for missing/invalid fields is well-placed and uses the correct log level. However, consider including the transaction hash in these error logs to make debugging easier when issues occur.

🔎 Optional enhancement: Add transaction hash to error logs
 		decoded, ok := eventMap["decoded"].(map[string]interface{})
 		if !ok || decoded == nil {
-			logger.Errorf("Missing or invalid 'decoded' field in transfer event")
+			txHash, _ := eventMap["transaction_hash"].(string)
+			logger.WithFields(logger.Fields{
+				"txHash": txHash,
+			}).Errorf("Missing or invalid 'decoded' field in transfer event")
 			continue
 		}
 		nonIndexedParams, ok := decoded["non_indexed_params"].(map[string]interface{})
 		if !ok || nonIndexedParams == nil {
-			logger.Errorf("Missing or invalid 'non_indexed_params' in transfer event")
+			txHash, _ := eventMap["transaction_hash"].(string)
+			logger.WithFields(logger.Fields{
+				"txHash": txHash,
+			}).Errorf("Missing or invalid 'non_indexed_params' in transfer event")
 			continue
 		}
📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ea1a8a8 and fc47adc.

📒 Files selected for processing (1)
  • services/indexer/starknet.go (5 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
services/indexer/starknet.go (3)
utils/logger/logger.go (4)
  • Errorf (141-146)
  • WithFields (76-109)
  • Fields (73-73)
  • Infof (125-130)
utils/crypto/crypto.go (1)
  • NormalizeStarknetAddress (312-324)
ent/network/where.go (1)
  • GatewayContractAddress (85-87)
⏰ 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: build-and-test
🔇 Additional comments (3)
services/indexer/starknet.go (3)

1-629: Critical: PR objectives don't match implemented changes.

The PR description and linked issue #407 focus on priority queue enhancements to save previous provider rates and check both current and previous rates during order assignment. However, the actual code changes only add logging statements to the Starknet indexer.

Expected changes based on PR objectives:

  • Modifications to CreatePriorityQueueForBucket to save previous queues with _prev suffix
  • Updates to AssignLockPaymentOrder to check both current and previous queues
  • Redis key management for _prev suffixed keys

None of these changes are present in this file. Please verify:

  1. Is this PR addressing issue #407 or a different task?
  2. Are the priority queue changes in a different file not included in this review?
  3. Should the PR description be updated to reflect the actual logging improvements?

319-328: LGTM: Well-structured logging for successful transfer processing.

This Info-level log is appropriately placed and includes comprehensive context (token, addresses, values, block number, transaction hash). It fires only after validation, making it suitable for tracking successfully processed transfers.


286-290: LGTM: Proper error handling for value parsing.

The error handling correctly logs parsing failures with context and continues processing remaining events rather than failing the entire batch.

@onahprosper onahprosper merged commit 6b59e56 into main Dec 20, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Save previous provider rates in priority queue to reduce order failures

3 participants