fix: surface bridge deposit errors instead of failing silently#2329
Open
kushagrasarathe wants to merge 2 commits into
Open
fix: surface bridge deposit errors instead of failing silently#2329kushagrasarathe wants to merge 2 commits into
kushagrasarathe wants to merge 2 commits into
Conversation
EEA-uplift users whose docs are under Bridge review were retrying deposits
with zero feedback: the onramp hook threw a hardcoded message without
reading the backend's { error } body, the page's catch read the hook's
error state before it flushed (always null on first attempt), and the
waiting-on-provider gate dead-ended the Continue button with no message.
Parse the error body, show the caught message directly, and tell
under-review users their verification is being processed.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
Important Review skippedNo new commits to review since the last review. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Warning Walkthrough skippedFile diffs could not be summarized. Comment |
Contributor
Code-analysis diffPainscore total: 5860.66 → 5861.65 (+0.99) 🆕 New findings (12)
✅ Resolved (12)
📈 Painscore deltas (top movers)
|
Contributor
🧪 UI test report — ✅ all greenSuites
📊 Coverage (unit)
⏱ 10 slowest test cases
|
Addresses code-review findings on the silent-failure fix: - only surface the backend body for 4xx (client errors); 5xx bodies carry raw internal messages the global handler doesn't sanitize, so those fall back to the generic string (no internal-detail leak). - make useCreateOnramp throw-only: its React error state had no reader after the page stopped destructuring it, and was the same stale-closure trap the page fix works around. The thrown Error carries the reason. - reuse gate.userMessage for the waiting-on-provider copy instead of hardcoding, matching every other gate consumer. - extract GENERIC_ONRAMP_ERROR so the fallback copy lives in one place. - keep the distinct 'Unknown error' analytics label for non-Error throws.
Contributor
Author
|
@coderabbitai review |
Contributor
✅ Action performedReview finished.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
EEA-uplift users whose Bridge KYC docs are under review were creating deposits that failed with zero feedback — they retried blind (user recording confirmed; ~369 prod users currently sit in the waiting-on-provider state). Three silent-failure holes on the bank deposit path:
useCreateOnrampthrew a hardcoded generic message without parsing the backend's{ error }body (the comment claimed it parsed; it didn't). Backend reasons like "Could not create transfer: customer is under review" were discarded.errorstate, which hasn't flushed when the synchronous catch runs — alwaysnullon first attempt, so nothing displayed.gate.kind === 'waiting-on-provider'silently no-op'd the Continue button — no "under review" UX existed anywhere.Fix: parse the error body (
error/messagekeys, generic fallback), show the caught message directly in the catch, and show a friendly "your verification details are being reviewed" message on the waiting-on-provider gate.Risks / breaking changes
QA
npm test— 107 suites green, incl. newuseCreateOnramphook tests + 2 page tests (error surfacing with unflushed hook state; waiting-on-provider message instead of dead button).error: null→ nosetErrorcall), new code passes.REQUIRES_EXTRA_INFORMATION+kyc_approvalwait signal → deposit → Continue now shows the under-review message.