fix(send): hide 'Exchange or Wallet' dead-button card in direct-send flow#2225
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
More reviews will be available in 41 minutes and 31 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
Comment |
Code-analysis diffPainscore total: 5793.76 → 5793.77 (+0.01) 🆕 New findings (4)
✅ Resolved (4)
|
🧪 UI test report — ✅ all greenSuites
📊 Coverage (unit)
⏱ 10 slowest test cases
|
PaymentMethodActionList renders an 'Exchange or Wallet' card (soon:false, so enabled) whose tap only does anything when the caller passes onPayWithExternalWallet. The semantic-request flow passes it; the direct-send flow (SendInputView, non- logged-in users) does NOT — and direct-send has no external-wallet path at all (only Input/Status/Success views). So a guest who entered an amount and tapped the card got nothing: a dead button (audit HIGH finding, same class as the withdraw Continue throw). Fix at the component level so it's correct-by-construction for every caller: only render the exchange-or-wallet card when an onPayWithExternalWallet handler is provided. No caller can surface a card it can't honor. Semantic-request is unchanged (still passes the handler). Adds the component's first tests.
7f7085f to
fdf12fa
Compare
Why
A guest on
/sendwho enters an amount sees an 'Exchange or Wallet' card (soon:false, enabled) that does nothing when tapped.PaymentMethodActionListonly acts on that card when the caller passesonPayWithExternalWallet; the semantic-request flow does, but direct-send (SendInputView) does not — and direct-send has no external-wallet path (only Input/Status/Success views). Dead button. Found by the dead-button-class audit (HIGH), same family as the withdraw Continue throw (#2224).Fix
Filter the
exchange-or-walletcard out ofPaymentMethodActionListunless anonPayWithExternalWallethandler is provided — correct-by-construction: no caller can render a card it can't honor. Semantic-request unchanged (still passes the handler, card still shows). Not wiring a handler into direct-send because that flow has no external-wallet machinery — that would be a feature, not a bug fix.Test
Adds the component's first tests: card hidden without handler (+ other methods still render), shown + invokes handler (no /setup redirect) with handler. 2/2 pass.
Risk
Low, UI-only. Removes a non-functional option from the guest direct-send view; no behavior change for logged-in users or the request flow.