feat: chain-aware ENS resolution + visible resolved address in withdraw#2501
Conversation
ENS names can hold a different address per chain (ENSIP-11). The withdraw flow resolved every name to its mainnet record and sent on the selected chain — funds loss when the name points elsewhere on that chain (reported by an external ENS-savvy tester with test.ses.eth: mainnet and Arbitrum records differ). - resolveEns/validateAndResolveRecipient accept the destination chainId and forward it to /ens/:name?chainId= (api-ts #1236). - Switching chains after typing a name re-resolves it for the new chain instead of silently keeping the old address. - The resolved address is now shown under the input as soon as the name validates, and again in the compatibility warning modal — the user sees where funds go BEFORE any warning/confirm step.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Code-analysis diffPainscore total: 6265.6 → 6268.24 (+2.64) 🆕 New findings (20)
✅ Resolved (18)
📈 Painscore deltas (top movers)
|
🧪 UI test report — ✅ all greenSuites
📊 Coverage (unit)
⏱ 10 slowest test cases
|
|
@coderabbitai review |
✅ Action performedReview finished.
|
Conflict in Initial.withdraw.view.tsx: dev added a chain-switch effect that clears chain-scoped errors at the same spot as this branch's ENS re-resolve effect. Kept both as separate effects (separate prev-chain refs) — merging them would put error.showError in the re-resolve effect's deps and its cleanup would abort in-flight resolutions. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…flight Between switching chains and the new resolution landing, recipient.address still holds the previous chain's address and Review stayed clickable — the exact wrong-chain send this PR fixes, in a narrow race window. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Reviewed (Jota, via Claude Code). Two things pushed to the branch:
Also verified: client-side API #1236 is merged, so the |
crypto-withdraw-confirm.test.tsx (new on dev) mocks general.utils with only the functions the page used at the time; the compatibility-modal change now also renders printableAddress from that module. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Summary
Companion to peanut-api-ts#1236. External tester feedback on the withdraw flow's ENS handling:
test.ses.ethon Arbitrum went to its Ethereum address. The flow now passes the destinationchainIdthroughresolveEns→/ens/:name?chainId=, and switching chains after typing a name re-resolves it for the new chain (failure invalidates the input instead of keeping the stale address).0x…now renders under the input the moment the name validates ("name resolves to 0x1234…abcd"), and the "Is this address compatible?" modal shows the concrete destination address.Risks / breaking changes
chainIdquery param is ignored by the old route schema → behavior identical to today (mainnet record). No hard dependency, no breakage either way.GeneralRecipientInputgains an optionalchainIdprop — all other consumers unchanged (prop omitted = today's behavior).QA
src/lib/validation/recipient.test.ts: chainId forwarded toresolveEns; legacy callers resolve without it.🤖 Generated with Claude Code
Screenshots
Assets branch
pr-assets-2501is deleted post-merge.