2020 receipt fallback

[nischitpra]

Summary by CodeRabbit

• Bug Fixes
  • Improved reliability of block receipts retrieval across blockchain networks through enhanced error handling and automatic fallback mechanisms. When standard receipt requests encounter issues on supported networks, the system now automatically attempts alternative retrieval methods to ensure successful data collection.

[coderabbitai]

Walkthrough

This PR adds a chain-2020-specific fallback for eth_getBlockReceipts failures. After fetching blocks, the code detects receipt errors for chain 2020, extracts transaction hashes from the block data, and re-fetches receipts individually via eth_getTransactionReceipt to recover the failed entries.

Changes

Chain 2020 Block Receipts Fallback

Layer / File(s)

Summary

Fallback implementation and helpers internal/rpc/rpc.go

Adds fallbackBlockReceiptsForChain2020() to recover failed receipts by filtering errors, extracting transaction hashes from block data (supporting both string and object transaction formats), and re-fetching receipts per transaction. Includes isChain2020BlockReceiptsError() for error classification and extractTransactionHashes() for hash extraction from block transactions fields. Integrated via conditional check in the main receipt-processing flow when chain ID is 2020 and block receipts are enabled.

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'receipt fallback' directly refers to the core change—adding a post-processing fallback for eth_getBlockReceipts failures on chain 2020 with receipt re-fetching logic.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch np/receipt_fallback

---

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

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@internal/rpc/rpc.go`:
- Around line 487-491: The code clears receipt errors when
extractTransactionHashes(block.Result) returns an empty slice: change the logic
in the branch handling len(txHashes) == 0 so it does not overwrite
receipts[i].Error; only set receipts[i].Result = common.RawReceipts{} when
receipts[i].Error is already nil (preserve any existing error), and do not set
receipts[i].Error = nil unconditionally. Apply the same fix to the similar
parse-failure/no-transactions handling around the other extractTransactionHashes
usage (the block referenced at the other location) so parsing failures remain
visible and are not conflated with "no transactions".

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c383cba2-5d88-4797-b6b6-d96ab67865a7

📥 Commits

Reviewing files that changed from the base of the PR and between af5040e and ad91cc2.

📒 Files selected for processing (1)

• internal/rpc/rpc.go

[coderabbitai]

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Do not clear receipt errors when transaction extraction fails.

At Line 533-536, parse failure and “no transactions” are conflated (nil in both cases). Then at Line 487-491, len(txHashes)==0 clears the original receipt error and returns empty receipts. This can silently hide real receipt loss if block payload shape is unexpected.

💡 Suggested fix

-func extractTransactionHashes(block common.RawBlock) []string {
-	rawTransactions, ok := block["transactions"].([]interface{})
-	if !ok {
-		return nil
-	}
+func extractTransactionHashes(block common.RawBlock) ([]string, bool) {
+	rawTransactions, exists := block["transactions"]
+	if !exists {
+		return nil, false
+	}
+	txList, ok := rawTransactions.([]interface{})
+	if !ok {
+		return nil, false
+	}
 
-	txHashes := make([]string, 0, len(rawTransactions))
-	for _, rawTx := range rawTransactions {
+	txHashes := make([]string, 0, len(txList))
+	for _, rawTx := range txList {
 		switch tx := rawTx.(type) {
 		case string:
 			if tx != "" {
 				txHashes = append(txHashes, tx)
 			}
 		case map[string]interface{}:
 			if hash, ok := tx["hash"].(string); ok && hash != "" {
 				txHashes = append(txHashes, hash)
 			}
 		}
 	}
 
-	return txHashes
+	return txHashes, true
 }

-		txHashes := extractTransactionHashes(block.Result)
-		if len(txHashes) == 0 {
+		txHashes, parsed := extractTransactionHashes(block.Result)
+		if !parsed {
+			log.Warn().
+				Err(receipts[i].Error).
+				Str("block_number", blockNumber).
+				Msg("Skipping chain 2020 eth_getBlockReceipts fallback because transactions could not be parsed")
+			continue
+		}
+		if len(txHashes) == 0 {
 			receipts[i].Result = common.RawReceipts{}
 			receipts[i].Error = nil
 			continue
 		}

Also applies to: 533-536

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@internal/rpc/rpc.go` around lines 487 - 491, The code clears receipt errors
when extractTransactionHashes(block.Result) returns an empty slice: change the
logic in the branch handling len(txHashes) == 0 so it does not overwrite
receipts[i].Error; only set receipts[i].Result = common.RawReceipts{} when
receipts[i].Error is already nil (preserve any existing error), and do not set
receipts[i].Error = nil unconditionally. Apply the same fix to the similar
parse-failure/no-transactions handling around the other extractTransactionHashes
usage (the block referenced at the other location) so parsing failures remain
visible and are not conflated with "no transactions".