Skip to content

fix(ens): fix ENS lookup and address transaction receipt fetching#228

Open
AugustoL wants to merge 3 commits intoopenscan-explorer:release/v1.2.1-afrom
AugustoL:fix/ens-lookup-search
Open

fix(ens): fix ENS lookup and address transaction receipt fetching#228
AugustoL wants to merge 3 commits intoopenscan-explorer:release/v1.2.1-afrom
AugustoL:fix/ens-lookup-search

Conversation

@AugustoL
Copy link
Collaborator

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 rpcUrls map is keyed by CAIP-2 networkId strings (e.g. "eip155:1"), but three locations were accessing it with the numeric key 1, which always returned undefined. This caused ensService to always be null and all ENS resolution to silently fail.

Transaction Receipt Fix: When viewing ENS-resolved addresses (e.g. augustol.eth), the transaction history had three bugs:

  1. Auto-search showed only 1 tx due to a narrow block window restriction
  2. Parallel mode showed all txs as "Pending" because the local extractData didn't handle RPCProviderResponse wrappers
  3. Older txs showed "Confirmed" instead of "Success" because eth_getTransactionReceipt returns null on some RPCs and the fallback strategy didn't retry

Related Issue

Closes #217

Type of Change

  • Bug fix

Changes Made

ENS Lookup (commit c7b4548)

  • src/hooks/useSearch.ts: Fix rpcUrls[1]rpcUrls["eip155:1"] (main search bar ENS resolution)
  • src/hooks/useENS.ts: Fix both occurrences of rpcUrls[1]rpcUrls["eip155:1"] (address page reverse lookup and forward resolve hook)
  • src/components/pages/evm/address/index.tsx: Fix rpcUrls[1]rpcUrls["eip155:1"] (direct ENS resolution when navigating to an ENS name)

Transaction Auto-Search & Parallel Mode (commit a6d4198)

  • src/services/AddressTransactionSearch.ts: Remove searchToBlockRef restriction that limited auto-search to 1 tx
  • src/services/AddressTransactionSearch.ts: Fix parallel mode extractData to handle RPCProviderResponse wrapper

Receipt Fetching & Status Display (commit 12153bc)

  • src/services/AddressTransactionSearch.ts: Add fetchBlockReceipts() using eth_getBlockReceipts (1 RPC call per block instead of N individual calls) with graceful fallback to individual calls
  • src/services/AddressTransactionSearch.ts: Extract buildTransaction() helper to deduplicate 3x repeated tx construction code
  • src/services/AddressTransactionSearch.ts: Import shared extractData instead of duplicating parallel mode logic locally
  • src/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-confirmed CSS class

Checklist

  • I have run npm run format:fix and npm run lint:fix
  • I have run npm run typecheck with no errors
  • I have run tests with npm run test:run
  • I have tested my changes locally
  • I have updated documentation if needed
  • My code follows the project's architecture patterns

Additional Notes

The eth_getBlockReceipts approach 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 — unlike null from individual receipt calls which the strategy treats as a valid response.

@github-actions
Copy link

github-actions bot commented Feb 18, 2026

🚀 Preview: https://pr-228--openscan.netlify.app
📝 Commit: f02b08f2f6a7f54c081c71b40f6b943950598d17

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 AugustoL force-pushed the fix/ens-lookup-search branch from 12153bc to f02b08f Compare February 18, 2026 17:15
@josealoha666
Copy link

Testing Report

Tested both the staging version (0b6412f) and the PR preview (f02b08f) side by side using the address 0x08EEc580AD41e9994599BaD7d2a74A9874A2852c (augustol.eth, 730 txs).

ENS Resolution

  • Staging: navigating to /#/1/address/augustol.eth shows a blank page with error: "Could not resolve ENS name 'augustol.eth': No Ethereum mainnet RPC configured for ENS resolution" — completely broken
  • PR fix: resolves correctly, displays augustol.eth Primary badge and ENS App link ✅

Transaction Auto-Search (0x address)

Staging 0b6412f PR f02b08f
Transactions found 1 5
Block range searched 24,420,838 → 24,420,838 (single block) 24,348,144 → 24,420,838 (~72K blocks)
ENS reverse lookup ❌ Not set ✅ augustol.eth Primary
Status display ✓ Success ✓ Success (all)

The searchToBlockRef restriction on staging is clearly visible — it stops after a single block and shows only 1 transaction despite the address having 730 total. The PR fix searches a proper block range and returns 5 recent transactions immediately.

Receipt Status

All transactions in the PR preview correctly show ✓ Success. The removed "Confirmed" workaround badge is no longer present.

Performance (eth_getBlockReceipts)

The fetchBlockReceipts() change (1 RPC call per block instead of N individual calls) is the most impactful improvement for addresses with many transactions. For this address with 730 txs, this could reduce receipt-fetching RPC calls by 90%+.

Overall: all three bug fixes confirmed working. Ready to merge.

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.

3 participants

Comments