fix(ens): fix ENS lookup and address transaction receipt fetching#227
Closed
AugustoL wants to merge 3 commits intorelease/v1.2.1-afrom
Closed
fix(ens): fix ENS lookup and address transaction receipt fetching#227AugustoL wants to merge 3 commits intorelease/v1.2.1-afrom
AugustoL wants to merge 3 commits intorelease/v1.2.1-afrom
Conversation
v1.2.0-alpha
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 #217 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
🚀 Preview: https://pr-227--openscan.netlify.app |
… 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. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
AugustoL
changed the title
Collaborator
Author
|
Recreating PR from fork |
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
1 participant
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.