fix(card): reopen WebSDK on Sumsub level transition instead of timing out#2171
fix(card): reopen WebSDK on Sumsub level transition instead of timing out#2171Hugo0 wants to merge 2 commits into
Conversation
… out The card-apply flow can chain TWO Sumsub levels: MAIN (e.g. Rain-required SELFIE) followed by `rain-card-application` (occupation/salary/purpose questionnaire). When the user finished MAIN, the next /rain/cards call returned `status:'incomplete'` with a new token at the next level — `handleSumsubComplete`'s "poll until non-incomplete" loop read that as "Sumsub auto-review still pending" and timed out at 15s, leaving the user on a generic "Verification is taking longer than expected" error instead of progressing to the questionnaire. Track the level the WebSDK was opened at; on close, branch: - just-completed MAIN → single fetch, reopen WebSDK at the new level - just-completed `rain-card-application` → keep the existing poll-for-settle `resolvePostSumsubAction` encapsulates the dispatch so the rule is unit-testable; covers the level transition, the skip-to-terms edge case (returning user with questionnaire pre-filled), poll-timeout, abort, and error-propagation paths.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
More reviews will be available in 27 minutes and 37 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ 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 (3)
Comment |
Code-analysis diffPainscore total: 5835.46 → 5837.54 (+2.08) 🆕 New findings (5)
✅ Resolved (4)
📈 Painscore deltas (top movers)
|
🧪 UI test report — ✅ all greenSuites
📊 Coverage (unit)
⏱ 10 slowest test cases
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
…iveness guard Two /code-review follow-ups on the prior commit: 1. Analytics drift on the reopened (action-level) WebSDK: `handleSumsubComplete` sets `sumsubCompletedRef.current = true` at entry so a subsequent close of the just-completed WebSDK doesn't fire `CARD_SUMSUB_CLOSED`. But the new `reopen-websdk` branch immediately opens the SDK AGAIN at the next level, and if the user abandons the questionnaire there, the flag is still `true` from the MAIN completion → `handleSumsubClose` skips the abandonment metric. Reset to `false` inside the `reopen-websdk` case before the new `setSumsubToken` so questionnaire abandonment is counted. 2. Switch on `action.kind` had no `default`. Adding a future variant to `PostSumsubAction` would silently fall through. Add the `_exhaustive: never = action` pattern so TS catches it at compile time.
Summary
Card-apply can chain two Sumsub levels back-to-back: MAIN (e.g. Rain-required SELFIE after liveness was added to the level config) followed by
rain-card-application(occupation / salary / purpose / monthly-volume questionnaire). When the user finishes MAIN, the BE's next/rain/cardscall returnsstatus: 'incomplete'with a new token atrain-card-application— that's a level transition, not "Sumsub auto-review still pending".The old
handleSumsubCompletepolled "until status != incomplete" for 15s, read the level-transition response as still pending, timed out, and surfaced "Verification is taking longer than expected. Please try again." Users on a single-level path were fine; users in the MAIN→action chain (anyone whose existing Sumsub applicant was missing a doc Rain's level config now requires) hit a wall.This PR:
lastSumsubLevelRef).resolvePostSumsubActionbranches on that level:incomplete + new token, reopen the WebSDK atrain-card-application. Falls through toadvancein the edge case where BE skips straight toterms-required(returning user whose questionnaire was already filled).rain-card-application→ keep the existing poll-for-settle behavior (Sumsub auto-review for the questionnaire really can be eventually consistent).reopen-websdk/advance/timeout/aborted); the page just switches onkind.The existing
pollUntilApplyAdvanceshelper is untouched — semantics preserved for callers that aren't on the level-transition path.Risks
Test plan
npx jest src/components/Card/__tests__/cardApply.utils.test.ts— 14/14 pass (6 existing + 8 new forresolvePostSumsubActioncovering: MAIN→reopen, MAIN→skip-to-terms edge, normal action-level advance, poll timeout, signal-aborted-on-entry, signal-aborted-mid-poll, null-level fallback, fetch-error propagation).npm run typecheckclean on changed files (one pre-existingSEOFooter.tsxworktree-submodule artifact, unrelated).pnpm prettier --checkclean.pnpm eslintclean on changed files./code-reviewpass.rain-card-applicationinstead of error-screen; complete questionnaire; proceeds to terms-required → card issued. Regression: confirm single-level path (all main docs present) still polls-and-advances as before.Out of scope (follow-ups)
byExternalActionIdAPI quirk: returns 404 for an action thatbyActionId/onereturns 200 for. Existing list-fallback insrc/sumsub/service.ts:319-333already masks it functionally; worth filing with Sumsub support, not blocking this PR.WAITLIST_SKIPbadge not in BE'sSKIP_BADGE_CODESallowlist — separate small PR on peanut-api-ts, best gated on Konrad's [TASK-12497] Feat/context instead of storage #953 foundation landing.