Conversation
…ll-crash fix(add-money): stop page crash when FX rate fails to load (PEANUT-UI-PS7)
PEANUTMAN_LOGO was the peanut-character illustration mislabeled as a
"logo" — distinct from the app icon (peanut-icon.svg) and the PEANUT
wordmark (PEANUT_LOGO). The name described where it was first used (a
header), not what it depicts.
- Rename export PEANUTMAN_LOGO -> PEANUTMAN and file
mascot/peanut-logo.svg -> mascot/peanutman.svg; update all call sites,
the local ASSET_ var, and the mascot alt text ("logo" -> "Peanut mascot").
- Move PEANUT_LOGO_BLACK out of illustrations/ into logos/ (it's the brand
logo); fix the one subpath import.
No behavior change — same pixels, accurate names. public/peanutman-logo.svg
is retained unchanged as the external email/embed alias.
Co-authored-by: kushagrasarathe <kushagrasarathe@gmail.com>
refactor(assets): name the mascot a mascot, not a logo
…nterval The verification-progress modal polled initiateSumsubKyc — a mutating endpoint — every 5s for the whole modal-open as a websocket fallback. For approved-LATAM users in the self-recovery state each call re-runs a full provider submission (86 in 20 min for one user, 2026-07-02); even with the BE cooldown each poll still costs ~3 provider calls + DB writes. Replace the fixed setInterval with a self-rescheduling setTimeout chain on a time-escalating schedule (5s for the first minute, then 10s → 20s → 60s) and stop polling after a ~15 min cap. The backoff is time-based, not error-based: the poll returns HTTP 200 even when the backend reprocess fails, so an error count would never escalate. The websocket stays the primary signal and the modal keeps its existing long-running state after the cap; re-opening restarts polling fresh.
fix(kyc): back off verification-progress poll instead of a fixed 5s interval
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 26 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (30)
Comment |
Code-analysis diffPainscore total: 5859.57 → 5872.71 (+13.14) 🆕 New findings (32)
…and 12 more. ✅ Resolved (27)
…and 7 more. 📈 Painscore deltas (top movers)
|
🧪 UI test report — ✅ all greenSuites
📊 Coverage (unit)
⏱ 10 slowest test cases
|
…6-07-02 chore: back-merge main → dev (2026-07-02 hotfix wave)
…ce, never hard-stops The 15-min KYC_POLL_CAP_MS stopped the fallback poll entirely, so a websocket event missed during a long manual review (laptop sleep, mobile background, network switch) left the user on 'Almost there' forever with onKycSuccess never firing. The poll now settles at the 60s floor and keeps going for the whole modal-open lifetime; the backend self-recovery cooldown bounds the per-call cost, so it's nothing like the fixed-5s battering ram the schedule replaced. Regression tests: keeps polling past 15 min (bounded ~10 calls in the following 10 min, not zero, not a flood) and a late APPROVED still fires onKycSuccess.
Companion to peanut-api-ts#1119. Users whose email was never captured used to dead-end on 'message support' (their only fix was a ticket); the BE now emits a provide-email NextAction for those rails, and this renders it: an email form (ActionModal, BridgeTosStep shell) wired into the two places the block surfaces — the home activation CTA and the bank add/withdraw gate. Saving posts update-user (first-time email set is allowed while KYC-locked) and the BE flips the rails to PENDING and resubmits automatically.
…tract, shadowing, copy getKycModalVariant maps provide-email to 'blocked' so unwired gate consumers keep the contact-support floor instead of a bogus re-verify CTA; the gate and ActivationCTAs both detect via the provide-email action kind (one contract, no reason-code divergence) and prefer an email-blocked rail over an earlier terminal one; the home CTA copy now says 'Add your email / Add email' instead of promising support and opening a form; the sheet resets on reopen and guards a not-yet-loaded userId.
feat(kyc): provide-email sheet for the no-email verification dead-end
fix(kyc): verification poll never hard-stops — no user strand (post-merge /code-review)
…6-07-03-ui chore: back-merge main → dev (offramp migration deposit + invite fixes)
…sistently (final /code-review) Final pre-prod review of the #2342 provide-email surfaces found two consumer sites diverging from the canonical deriveGate order (email-blocked > fixable): - ActivationCTAs: the copy memo ranked hasFixableRejection above isEmailBlocked while the button onClick ranked isEmailBlocked first — so with both rail states the card said 'Upload document' but opened the email sheet, and hid the document path. Reordered the memo (+ primaryRejectionMessage) to email-blocked → fixable → terminal, matching onClick and deriveGate. - AddWithdrawCountriesList.handleFormSubmit: missing the provide-email branch that checkBridgeGate has, so a rail flipping to email-blocked between form-open and submit opened the contact-support KYC modal instead of the email sheet — the exact self-serve→support-ticket regression #2342 fixes. Added the branch; regression test pins provide-email → sheet, not modal. Follow-up (not blocking): ActivationCTAs re-implements gate ordering inline; it should consume deriveGate directly so consumers can't drift again. Full suite 1675 green; typecheck clean.
…onsistency fix(kyc): route email-blocked gates to the self-serve email sheet consistently (final /code-review)
Release payload (dev-only commits)
Low-risk release; no service-worker version bump needed (no breaking API changes).