the ens names show for addresses where i typed in the ens name when sending, but not for other addresses that definitely have reverse ens names. please fix.
the ens names show for addresses where i typed in the ens name when sending, but not for other addresses that definitely have reverse ens names. please fix.
In both addressDetail.js and addressToken.js, the ENS reverse lookup code only collected one address per transaction — the counterparty based on send/receive direction. This had two bugs:
For contract interactions, the wrong side was resolved (tx.from instead of tx.to)
When clicking into transaction detail, both tx.fromEns and tx.toEns were read from the ENS map, but only one side was ever looked up
The fix: collect ALL unique from and to addresses for ENS resolution instead of just the counterparty. This ensures every displayed address gets a reverse ENS lookup via provider.lookupAddress().
**Root cause found and fixed in PR #25.**
In both `addressDetail.js` and `addressToken.js`, the ENS reverse lookup code only collected one address per transaction — the counterparty based on send/receive direction. This had two bugs:
1. For contract interactions, the wrong side was resolved (`tx.from` instead of `tx.to`)
2. When clicking into transaction detail, both `tx.fromEns` and `tx.toEns` were read from the ENS map, but only one side was ever looked up
The fix: collect ALL unique `from` and `to` addresses for ENS resolution instead of just the counterparty. This ensures every displayed address gets a reverse ENS lookup via `provider.lookupAddress()`.
Investigating. The ENS reverse resolution code (src/shared/ens.js) uses ethers.JsonRpcProvider.lookupAddress() which should work. Possible causes:
The RPC endpoint (ethereum-rpc.publicnode.com) may not support eth_call to the ENS reverse registrar
Cache corruption — results are cached for 12h in localStorage; a null result gets cached and blocks retries
getProvider() creates a new provider instance each call, which may cause connection/timeout issues
Will investigate further and test with different RPC endpoints.
Investigating. The ENS reverse resolution code (`src/shared/ens.js`) uses `ethers.JsonRpcProvider.lookupAddress()` which should work. Possible causes:
1. The RPC endpoint (`ethereum-rpc.publicnode.com`) may not support `eth_call` to the ENS reverse registrar
2. Cache corruption — results are cached for 12h in localStorage; a `null` result gets cached and blocks retries
3. `getProvider()` creates a new provider instance each call, which may cause connection/timeout issues
Will investigate further and test with different RPC endpoints.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
it's just showing the bare plain address, even though it has a .eth reverse
the ens names show for addresses where i typed in the ens name when sending, but not for other addresses that definitely have reverse ens names. please fix.
Taking this — investigating reverse ENS lookup logic now.
Root cause found and fixed in PR #25.
In both
addressDetail.jsandaddressToken.js, the ENS reverse lookup code only collected one address per transaction — the counterparty based on send/receive direction. This had two bugs:tx.frominstead oftx.to)tx.fromEnsandtx.toEnswere read from the ENS map, but only one side was ever looked upThe fix: collect ALL unique
fromandtoaddresses for ENS resolution instead of just the counterparty. This ensures every displayed address gets a reverse ENS lookup viaprovider.lookupAddress().Investigating. The ENS reverse resolution code (
src/shared/ens.js) usesethers.JsonRpcProvider.lookupAddress()which should work. Possible causes:ethereum-rpc.publicnode.com) may not supporteth_callto the ENS reverse registrarnullresult gets cached and blocks retriesgetProvider()creates a new provider instance each call, which may cause connection/timeout issuesWill investigate further and test with different RPC endpoints.