Better cashtab-connect error handling

[Klakurka]

Description

I was running into issues w/ my Brave extensions and noticed that the fallback to using cashtab.com wasn't working. I've introduced some more robust error handling. During build, it will no longer show the warnings that we're importing but not using some of the cashtab-connect error handling.

Test plan

Make sure cashtab extension + .com open as appropriate when clicking "Send with Cashtab".

Summary by CodeRabbit

• Bug Fixes
  • Improved payment flow reliability when the browser extension is unavailable or times out.
  • Ensured the app falls back to the web payment page in more error scenarios to reduce failed payments.
  • Handles user-denied address requests gracefully by stopping the flow without causing errors.

[coderabbitai]

Walkthrough

openCashtabPayment in react/lib/util/cashtab.ts was rewritten to compute the web fallback URL before trying the extension, await the extension call when present, and ensure all error paths either return early or fall back to opening the web URL.

Changes

Cohort / File(s)	Change Summary
Cashtab payment flow react/lib/util/cashtab.ts	Compute webUrl upfront from fallbackUrl or default; convert extension call to await cashtab.sendBip21(bip21Url); handle extension-unavailable and timeout errors by opening webUrl and returning; treat address-denied with an immediate return; use web fallback for unknown errors.

Sequence Diagram

sequenceDiagram
    participant Caller
    participant openCashtabPayment
    participant CashtabExt
    participant WebFallback

    Caller->>openCashtabPayment: call(bip21Url, fallbackUrl)
    Note over openCashtabPayment: compute webUrl = fallbackUrl || default

    alt extension available
        openCashtabPayment->>CashtabExt: await sendBip21(bip21Url)
        CashtabExt-->>openCashtabPayment: success
    else address denied
        Note over openCashtabPayment: user denied -> return
    else extension unavailable or timeout
        openCashtabPayment->>WebFallback: open(webUrl)
        openCashtabPayment-->>Caller: return
    else unknown error
        openCashtabPayment->>WebFallback: open(webUrl)
        openCashtabPayment-->>Caller: return
    end
    openCashtabPayment-->>Caller: done

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify async/await usage around cashtab.sendBip21 and no unhandled rejections
• Confirm all error branches reliably open webUrl or return as intended
• Check fallbackUrl and default URL handling for null/undefined cases

Poem

🐰 A tiny rabbit hops to pay,
Awaits the extension, then finds a way,
If doors are closed, the web will gleam,
Fallback ready, steady stream,
Cashtab's path now neat and fey.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: improved error handling for cashtab-connect functionality.
Description check	✅ Passed	The description includes the required sections (Description and Test plan) with adequate detail about the problem and testing approach, though the 'Related to #' issue reference is missing.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/cashtab-not-opening

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 187a38a and 3db6ee6.

📒 Files selected for processing (1)

• react/lib/util/cashtab.ts (1 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• react/lib/util/cashtab.ts

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Run build

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

react/lib/util/cashtab.ts (1)

87-94: Approve with optional consistency suggestion.

The await on sendBip21 is correct and enables proper error handling. The logic flow is sound.

For consistency with the error handlers below (which use early returns), consider adding an explicit return after line 93:

    } else {
      window.open(webUrl, '_blank');
+     return;
    }

This makes the control flow more explicit and consistent, though the current code is functionally correct.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6e96e22 and 187a38a.

📒 Files selected for processing (1)

• react/lib/util/cashtab.ts (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Run build

🔇 Additional comments (3)

react/lib/util/cashtab.ts (3)

1-6: LGTM! Imports are now properly utilized.

All imported error types are now used in the openCashtabPayment function's error handling logic and re-exported for consumers. This resolves the build warnings about unused imports mentioned in the PR objectives.

---

84-86: Excellent fix: webUrl computed upfront ensures reliable fallback.

Computing the web URL outside the try/catch block is the key improvement that fixes the fallback issue. This ensures the fallback URL is always available in all error paths, regardless of when or where errors occur.

---

95-110: Excellent error handling improvements!

The error handling hierarchy is well-structured and comprehensive:

1. User rejection → Respects user choice by doing nothing
2. Extension unavailable or timeout → Falls back to web (fixes the core issue)
3. Unknown errors → Falls back to web (defensive, ensures users can complete transactions)

The explicit instanceof checks for each error type are type-safe, and the early returns prevent fall-through. This implementation directly addresses the PR objective of fixing the fallback behavior when Brave extensions interfere.