fix(ens): fix ENS lookup and address transaction receipt fetching#228
Merged
AugustoL merged 3 commits intoopenscan-explorer:release/v1.2.1-afrom Feb 19, 2026
Merged
Conversation
|
🚀 Preview: https://pr-228--openscan.netlify.app |
rpcUrls is keyed by CAIP-2 networkId strings (e.g. "eip155:1"), but useSearch, useENS, and the address page were accessing it with the numeric key 1, which always returned undefined. This caused ENS resolution to silently fail with "No Ethereum mainnet RPC configured". Fixes openscan-explorer#217
… mode Two bugs fixed: 1. Auto-search (findRecentActivityRange) was restricting the search to the nearest block range where state changed, meaning if only 1 tx existed in that recent window the search stopped at 1 regardless of the searchLimit=5. Removing the fromBlock restriction lets the binary search scan the full chain and find the N most recent txs. 2. AddressTransactionSearch.extractData was using array[0] for parallel strategy responses, returning the RPCProviderResponse wrapper object instead of the inner RPC data. This caused block fetches to silently return no transactions (block.transactions === undefined) and receipt fetches to produce receipt.status === "success" (wrapper field) instead of "0x1"/"0x0", so every tx showed as Pending. Fixed the helper to detect the RPCProviderResponse shape and extract successfulResponse.data. Also adds a "Confirmed" status badge for mined txs whose receipt is unavailable (blockNumber present but no receipt.status), so they no longer incorrectly show as Pending.
Replace N individual eth_getTransactionReceipt calls with a single eth_getBlockReceipts call per block. This fixes older transactions showing incorrect status because the fallback RPC strategy treated null receipts as valid responses without trying other providers. - Add fetchBlockReceipts() using eth_getBlockReceipts with graceful fallback - Extract buildTransaction() helper to deduplicate tx construction (3x) - Import shared extractData instead of duplicating parallel mode logic - Remove "Confirmed" status badge (was a workaround for missing receipts) - Remove unused .table-status-confirmed CSS class
AugustoL
force-pushed
the
fix/ens-lookup-search
branch
from
12153bc to
f02b08f
Compare
Testing ReportTested both the staging version ( ENS Resolution
Transaction Auto-Search (0x address)
The Receipt StatusAll transactions in the PR preview correctly show ✓ Success. The removed "Confirmed" workaround badge is no longer present. Performance (eth_getBlockReceipts)The Overall: all three bug fixes confirmed working. Ready to merge. |
MatiasOS
approved these changes
Feb 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Fix ENS lookup not working in search inputs and address page, and fix address transaction history showing incorrect status for older transactions.
ENS Lookup Fix: The
rpcUrlsmap is keyed by CAIP-2 networkId strings (e.g."eip155:1"), but three locations were accessing it with the numeric key1, which always returnedundefined. This causedensServiceto always benulland all ENS resolution to silently fail.Transaction Receipt Fix: When viewing ENS-resolved addresses (e.g.
augustol.eth), the transaction history had three bugs:extractDatadidn't handleRPCProviderResponsewrapperseth_getTransactionReceiptreturnsnullon some RPCs and the fallback strategy didn't retryRelated Issue
Closes #217
Type of Change
Changes Made
ENS Lookup (commit c7b4548)
src/hooks/useSearch.ts: FixrpcUrls[1]→rpcUrls["eip155:1"](main search bar ENS resolution)src/hooks/useENS.ts: Fix both occurrences ofrpcUrls[1]→rpcUrls["eip155:1"](address page reverse lookup and forward resolve hook)src/components/pages/evm/address/index.tsx: FixrpcUrls[1]→rpcUrls["eip155:1"](direct ENS resolution when navigating to an ENS name)Transaction Auto-Search & Parallel Mode (commit a6d4198)
src/services/AddressTransactionSearch.ts: RemovesearchToBlockRefrestriction that limited auto-search to 1 txsrc/services/AddressTransactionSearch.ts: Fix parallel modeextractDatato handleRPCProviderResponsewrapperReceipt Fetching & Status Display (commit 12153bc)
src/services/AddressTransactionSearch.ts: AddfetchBlockReceipts()usingeth_getBlockReceipts(1 RPC call per block instead of N individual calls) with graceful fallback to individual callssrc/services/AddressTransactionSearch.ts: ExtractbuildTransaction()helper to deduplicate 3x repeated tx construction codesrc/services/AddressTransactionSearch.ts: Import sharedextractDatainstead of duplicating parallel mode logic locallysrc/services/AddressTransactionSearch.ts: Remove useless retry block (was retrying same RPC → same null result)src/components/pages/evm/address/shared/TransactionHistory.tsx: Remove "Confirmed" status badge (was a workaround for missing receipts)src/styles/tables.css: Remove unused.table-status-confirmedCSS classChecklist
npm run format:fixandnpm run lint:fixnpm run typecheckwith no errorsnpm run test:runAdditional Notes
The
eth_getBlockReceiptsapproach is more reliable because if an RPC has the block, it has all its receipts (stored together). If the method is unsupported, it returns an error which properly triggers fallback — unlikenullfrom individual receipt calls which the strategy treats as a valid response.