feat(onboarding): enhance error reporting in KycModal, Navbar, and wa… - #507
Open
sundayonah wants to merge 10 commits into
Open
feat(onboarding): enhance error reporting in KycModal, Navbar, and wa…#507sundayonah wants to merge 10 commits into
sundayonah wants to merge 10 commits into
Conversation
…llet contexts - Integrated `reportClientError` for improved error handling in KycModal during KYC signing and initiation processes. - Added error reporting in Navbar for login and signup completion, capturing relevant context. - Enhanced error handling in InjectedWalletContext and StarknetContext to report issues during wallet connection and creation. - Updated `reportClientError` function to include additional tags for better tracking of errors related to onboarding flows.
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR adds structured client-side error reporting to onboarding, KYC, and wallet initialization flows. It also updates Sentry client tagging so reported errors carry selected context fields as tags. ChangesOnboarding Flow Error Tracking
Estimated code review effort: 4 (Complex) | ~45 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@app/context/StarknetContext.tsx`:
- Around line 179-187: The wallet-creation failure is being reported multiple
times from the same flow; to fix, add a simple dedupe guard (e.g., a module- or
context-scoped Set or boolean) keyed to this flow so reportClientError is only
called once per failed wallet-creation attempt. Update the call sites in
StarknetContext where reportClientError is invoked (the branches inside
createWallet, ensureWalletExists, and the !response.ok handler) to check the
dedupe key (for example "starknet-create-wallet") before reporting and mark the
key as reported after the first call; keep throwing the Error as before so
control flow is unchanged. Ensure the dedupe key is unique to this flow so other
errors still get reported.
- Around line 216-220: The catch only logs thrown exceptions but ignores non-OK
HTTP responses from the /api/starknet/get-public-key call; update the request
handling around the fetch that leads to reportClientError so that after
receiving the Response you check response.ok and, if false, parse the response
body (safely handle JSON parse errors), then call reportClientError (the same
reporting path that uses pkError) with explicit context including status,
statusText and any parsed error payload and the feature/flow/step metadata;
ensure successful paths remain unchanged and only non-OK responses invoke the
new explicit reporting.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 76063cf5-5579-43ef-96d1-7aff0e709bd6
📒 Files selected for processing (5)
app/components/KycModal.tsxapp/components/Navbar.tsxapp/context/InjectedWalletContext.tsxapp/context/StarknetContext.tsxapp/lib/sentry.client.ts
Collaborator
|
@sundayonah please address coderabbit |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
app/components/KycModal.tsx (1)
1411-1495: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winPreserve the HTTP status on
fetchStatusfailures
reportClientErroronly tags a numericstatusCode, but the non-404fetchfailure throws a plainError, so this path always sendsundefinedand loses the response code for GlitchTip filtering. Attachres.statusto the thrown error or pass it through toreportClientErrordirectly.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/components/KycModal.tsx` around lines 1411 - 1495, The fetchStatus error path is dropping the HTTP status code because the non-404 branch throws a plain Error, so reportClientError receives undefined for statusCode. Update fetchStatus in KycModal to preserve the response status when res.ok is false, either by attaching res.status to the thrown error or by passing the status directly into reportClientError. Use the fetchStatus function and the reportClientError call in KycModal as the main places to fix.
🧹 Nitpick comments (1)
app/components/KycModal.tsx (1)
309-329: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDuplicate statusCode-extraction logic — extract a shared helper.
The same axios-style status extraction is repeated verbatim in the
handleSmilePublishcatch (Lines 314-318) and thefetchStatuscatch (Lines 1480-1484). Consider a small local helper to keep both call sites consistent and easier to maintain.♻️ Suggested helper
+const getAxiosStatusCode = (error: unknown): number | undefined => { + const status = (error as { response?: { status?: unknown } })?.response + ?.status; + return typeof status === "number" ? status : undefined; +}; + const handleSmilePublish = async (event: Event) => {Then in each catch block:
- statusCode: - typeof (error as { response?: { status?: unknown } })?.response - ?.status === "number" - ? (error as { response?: { status?: number } }).response?.status - : undefined, + statusCode: getAxiosStatusCode(error),Also applies to: 1382-1386, 1476-1487
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/components/KycModal.tsx` around lines 309 - 329, The axios response status extraction is duplicated across the KycModal catch blocks in handleSmilePublish and fetchStatus, so factor it into a shared local helper and use that helper in both places. Add a small reusable function near the related handlers that safely reads response.status from an unknown error and returns undefined otherwise, then update reportClientError call sites to use it so both code paths stay consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@app/components/KycModal.tsx`:
- Around line 1320-1403: The Tier 3 submit handler in KycModal’s onClick is
missing client error reporting in the non-OK response path. Update the !res.ok
branch in the `/api/kyc/tier3-verify` fetch flow to call reportClientError with
the response failure details before toasting and setting failure state. Keep the
existing outer catch reporting, and make sure this branch covers 4xx/5xx server
responses just like the exception path.
---
Outside diff comments:
In `@app/components/KycModal.tsx`:
- Around line 1411-1495: The fetchStatus error path is dropping the HTTP status
code because the non-404 branch throws a plain Error, so reportClientError
receives undefined for statusCode. Update fetchStatus in KycModal to preserve
the response status when res.ok is false, either by attaching res.status to the
thrown error or by passing the status directly into reportClientError. Use the
fetchStatus function and the reportClientError call in KycModal as the main
places to fix.
---
Nitpick comments:
In `@app/components/KycModal.tsx`:
- Around line 309-329: The axios response status extraction is duplicated across
the KycModal catch blocks in handleSmilePublish and fetchStatus, so factor it
into a shared local helper and use that helper in both places. Add a small
reusable function near the related handlers that safely reads response.status
from an unknown error and returns undefined otherwise, then update
reportClientError call sites to use it so both code paths stay consistent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 8fb0254e-5b3a-42c3-a95e-5f940208bc69
📒 Files selected for processing (3)
app/components/KycModal.tsxapp/components/Navbar.tsxapp/context/StarknetContext.tsx
💤 Files with no reviewable changes (1)
- app/context/StarknetContext.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- app/components/Navbar.tsx
Contributor
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
app/components/KycModal.tsx (1)
1411-1495: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winPreserve the HTTP status on
fetchStatusfailures
reportClientErroronly tags a numericstatusCode, but the non-404fetchfailure throws a plainError, so this path always sendsundefinedand loses the response code for GlitchTip filtering. Attachres.statusto the thrown error or pass it through toreportClientErrordirectly.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/components/KycModal.tsx` around lines 1411 - 1495, The fetchStatus error path is dropping the HTTP status code because the non-404 branch throws a plain Error, so reportClientError receives undefined for statusCode. Update fetchStatus in KycModal to preserve the response status when res.ok is false, either by attaching res.status to the thrown error or by passing the status directly into reportClientError. Use the fetchStatus function and the reportClientError call in KycModal as the main places to fix.
🧹 Nitpick comments (1)
app/components/KycModal.tsx (1)
309-329: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winDuplicate statusCode-extraction logic — extract a shared helper.
The same axios-style status extraction is repeated verbatim in the
handleSmilePublishcatch (Lines 314-318) and thefetchStatuscatch (Lines 1480-1484). Consider a small local helper to keep both call sites consistent and easier to maintain.♻️ Suggested helper
+const getAxiosStatusCode = (error: unknown): number | undefined => { + const status = (error as { response?: { status?: unknown } })?.response + ?.status; + return typeof status === "number" ? status : undefined; +}; + const handleSmilePublish = async (event: Event) => {Then in each catch block:
- statusCode: - typeof (error as { response?: { status?: unknown } })?.response - ?.status === "number" - ? (error as { response?: { status?: number } }).response?.status - : undefined, + statusCode: getAxiosStatusCode(error),Also applies to: 1382-1386, 1476-1487
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/components/KycModal.tsx` around lines 309 - 329, The axios response status extraction is duplicated across the KycModal catch blocks in handleSmilePublish and fetchStatus, so factor it into a shared local helper and use that helper in both places. Add a small reusable function near the related handlers that safely reads response.status from an unknown error and returns undefined otherwise, then update reportClientError call sites to use it so both code paths stay consistent.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@app/components/KycModal.tsx`:
- Around line 1320-1403: The Tier 3 submit handler in KycModal’s onClick is
missing client error reporting in the non-OK response path. Update the !res.ok
branch in the `/api/kyc/tier3-verify` fetch flow to call reportClientError with
the response failure details before toasting and setting failure state. Keep the
existing outer catch reporting, and make sure this branch covers 4xx/5xx server
responses just like the exception path.
---
Outside diff comments:
In `@app/components/KycModal.tsx`:
- Around line 1411-1495: The fetchStatus error path is dropping the HTTP status
code because the non-404 branch throws a plain Error, so reportClientError
receives undefined for statusCode. Update fetchStatus in KycModal to preserve
the response status when res.ok is false, either by attaching res.status to the
thrown error or by passing the status directly into reportClientError. Use the
fetchStatus function and the reportClientError call in KycModal as the main
places to fix.
---
Nitpick comments:
In `@app/components/KycModal.tsx`:
- Around line 309-329: The axios response status extraction is duplicated across
the KycModal catch blocks in handleSmilePublish and fetchStatus, so factor it
into a shared local helper and use that helper in both places. Add a small
reusable function near the related handlers that safely reads response.status
from an unknown error and returns undefined otherwise, then update
reportClientError call sites to use it so both code paths stay consistent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 8fb0254e-5b3a-42c3-a95e-5f940208bc69
📒 Files selected for processing (3)
app/components/KycModal.tsxapp/components/Navbar.tsxapp/context/StarknetContext.tsx
💤 Files with no reviewable changes (1)
- app/context/StarknetContext.tsx
🚧 Files skipped from review as they are similar to previous changes (1)
- app/components/Navbar.tsx
🛑 Comments failed to post (1)
app/components/KycModal.tsx (1)
1320-1403: 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Missing
reportClientErrorin the Tier 3!res.okpath (5xx/4xx from/api/kyc/tier3-verify).The outer
catch(Lines 1381-1396) now reports client errors, but the!res.okbranch (Lines 1346-1368) — which handles actual HTTP failure responses from the server, including 5xx — never callsreportClientError. It only logs to console and shows a toast. Per the linked issue's objective to report "network errors, 5xx responses, and unhandled exceptions," this is a gap: server-side failures on Tier 3 submission won't reach GlitchTip.🐛 Suggested fix
if (!res.ok) { let errorDetail = "Unable to submit Tier 3 verification."; try { const errJson = await res.json(); errorDetail = errJson?.error || errJson?.message || errJson?.details || errorDetail; } catch { try { const errText = await res.text(); if (errText) errorDetail = errText; } catch { // keep default } } + reportClientError(new Error(errorDetail), { + feature: "onboarding", + flow: "kyc", + step: "kyc-tier3-submit", + statusCode: res.status, + }); console.error("Tier 3 verification request failed:", errorDetail);📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.onClick={async () => { if (!tier3UploadedFile || tier3Submitting) return; setTier3Submitting(true); try { const accessToken = await getAccessToken(); if (!accessToken) { setTier3Submitting(false); toast.error("Session expired. Please sign in again."); return; } const formData = new FormData(); formData.append("file", tier3UploadedFile); formData.append("countryCode", tier3CountryCode); formData.append("documentType", tier3DocumentType); formData.append("houseNumber", tier3HouseNumber); formData.append("streetAddress", tier3StreetAddress); formData.append("county", tier3County); formData.append("postalCode", tier3PostalCode); const res = await fetch("/api/kyc/tier3-verify", { method: "POST", headers: { Authorization: `Bearer ${accessToken}` }, body: formData, }); if (!res.ok) { let errorDetail = "Unable to submit Tier 3 verification."; try { const errJson = await res.json(); errorDetail = errJson?.error || errJson?.message || errJson?.details || errorDetail; } catch { try { const errText = await res.text(); if (errText) errorDetail = errText; } catch { // keep default } } reportClientError(new Error(errorDetail), { feature: "onboarding", flow: "kyc", step: "kyc-tier3-submit", statusCode: res.status, }); console.error("Tier 3 verification request failed:", errorDetail); toast.error("Tier 3 verification failed", { description: errorDetail }); setFailedReason(errorDetail); setFailedRetryStep(STEPS.TIER3_UPLOAD); setStep(STEPS.STATUS.FAILED); setTier3Submitting(false); return; } const data = await res.json(); if (data?.success) { setStep(STEPS.STATUS.SUCCESS); } else { const errorDetail = data?.error || data?.message || "Tier 3 verification failed."; toast.error("Tier 3 verification failed", { description: errorDetail }); setFailedReason(errorDetail); setFailedRetryStep(STEPS.TIER3_UPLOAD); setStep(STEPS.STATUS.FAILED); } } catch (e) { reportClientError(e, { feature: "onboarding", flow: "kyc", step: "kyc-tier3-submit", }); console.error("Tier 3 verification error:", e); const msg = e instanceof Error ? e.message : "Tier 3 verification failed. Please try again."; toast.error(msg); setFailedReason(msg); setFailedRetryStep(STEPS.TIER3_UPLOAD); setStep(STEPS.STATUS.FAILED); } finally { setTier3Submitting(false); } }} > {tier3Submitting ? "Verifying…" : "Complete upgrade"} </button> </div> </motion.div> ); };🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@app/components/KycModal.tsx` around lines 1320 - 1403, The Tier 3 submit handler in KycModal’s onClick is missing client error reporting in the non-OK response path. Update the !res.ok branch in the `/api/kyc/tier3-verify` fetch flow to call reportClientError with the response failure details before toasting and setting failure state. Keep the existing outer catch reporting, and make sure this branch covers 4xx/5xx server responses just like the exception path.
- Added a mechanism to report onboarding errors only once per instance to reduce alert volume. - Integrated the new error reporting function in the StarknetProvider for wallet creation and public key derivation. - Updated error handling to ensure consistent messaging and logging for onboarding-related errors.
|
Bugbot is not enabled for this team, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
…er signup - Refactored the event tracking logic for user signup completion to enhance readability. - Updated variable names for clarity, specifically changing `walletAddress` to `signupWalletAddress`. - Improved error handling for the token fetch process during email signup, ensuring better logging of failures. - Maintained existing functionality while enhancing code clarity and maintainability.
|
Bugbot is not enabled for this team, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
…609) * feat: embeddable widget mode (/widget) for whitelisted partner sites Adds an iframe-embeddable compact swap widget, gated to whitelisted origins and matching the Figma widget design: - /widget route rendering the existing MainPageContent in a compact WidgetShell card (mobile UI, minimized wallet pill opening the wallet drawer, pinned "Secured by Noblocks" footer, sticky primary CTAs, close X outside the card, transparent backdrop so the host page shows through - includes a color-scheme override so Chrome doesn't paint an opaque canvas behind the cross-origin iframe). - Security: X-Frame-Options: DENY scoped away from /widget only; middleware emits a per-request CSP frame-ancestors allowlist merged from EMBED_ALLOWED_ORIGINS env and the new embed_allowed_origins Supabase table (secret-gated /api/internal/embed-origins CRUD, contact_email required per partner). Feature-flagged via NEXT_PUBLIC_EMBED_ENABLED (404 when off), fails closed to frame-ancestors 'none'. /widget noindexed via robots + metadata. - postMessage host API (EmbedContext): noblocks:ready / resize / close / tx_status, sent only to the verified embedder origin. - Host-wallet EIP-1193 bridge: ?injected=bridge proxies wallet requests to the host page's connected provider (WalletConnect/AppKit/wagmi) via public/embed.js NoblocksEmbed.bindWallet(); extends the existing ?injected=true extension-wallet path. - Analytics: no client trackers in the widget; cookieless server-side "Embed Widget Loaded" attribution with referrer origin via the middleware-analytics pipeline. ?theme=dark|light forces the theme. - Widget-scoped UI trims: no navbar/footer/hero/banners/cookie consent, no 30s strip, success screen with stacked full-width buttons and no share section; Brevo launcher repositioned inside the card. - General fix: wallet balances comma-formatted via formatCurrency (drawer total, navbar chip, per-token USD equivalents). - Partner docs in docs/embed-widget.md (whitelisting via info@noblocks.xyz). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(embed): address CodeRabbit review — HTTPS origins, SSRF-safe fetch, fail-closed cache, button ordering - Require HTTPS for partner embed origins (http:// only for localhost/127.0.0.1 in dev) in both middleware and the internal allowlist API. - Fetch the DB-backed allowlist only via a trusted, configured INTERNAL_API_BASE_URL instead of the request-derived (Host-controlled) origin, so a poisoned host can't leak INTERNAL_API_KEY or poison the shared cache. - Fail closed: drop DB-backed origins on a failed/non-OK allowlist refresh so a revoked partner can't keep framing during an outage (env allowlist stays). - Normalize + validate the DELETE origin the same way as POST (trailing slash no longer silently deletes nothing). - Success screen (embed): put New payment + Get receipt in one sticky wrapper (primary on top) so the stacking is unambiguous; restore the exact non-embed layout. - Docs: validate e.source === iframe.contentWindow in the message-listener example; bind the wallet before setting the iframe src. - Replace the Tailwind-class-coupled wallet-drawer selector with a stable .wallet-drawer-panel hook class. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs: add iframe embed quickstart to README linking to docs/embed-widget.md Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Drop the outside-the-card X and its 449px gutter unit: the close button now lives consistently in the card header next to the wallet pill, and the 393px card is centered with only its drop shadow around it. Simplifies the geometry (no responsive close-button swap), recenters the Brevo launcher and wallet drawer offsets, matches the WidgetPreloader skeleton, and updates the recommended iframe width in the docs/README (420px). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…idget card shadow MobileDropdown derived the header balance card's address only from useWallets() (Privy's wallet-connector list), which can lag behind user.linkedAccounts right after a fresh signup — before any smart wallet exists, this hid the entire address/balance card even though the per-network balance list below it (driven by useWalletAddress(), which already falls back to linkedAccounts) rendered correctly. Most visible on first-time /widget visitors, who are always fresh EOA users. Reuse useWalletAddress()'s address instead of re-deriving it locally. Also drop the WidgetShell card's drop shadow per design feedback — the card now sits flush with no shadow/ring, just the transparent backdrop. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…d text, contained overlays - WidgetShell now fills the entire iframe viewport (h-dvh, no margins, no shadow) — partners size/round/float the widget by styling the iframe element. Fixes the status/pending screen shrinking to fit (footer now stays pinned to the bottom edge) and naturally contains viewport-anchored overlays (bottom sheets, modals, Brevo launcher) within the card, so the centered-card width-cap CSS is gone. WidgetPreloader matches. - Theme: replace forcedTheme with a client-side, once-per-load sync — forcedTheme disabled next-themes' setTheme() entirely, dead-ending the Settings > Theme switcher in the widget; a dynamic defaultTheme can't work because the force-static layout bakes the anti-FOUC script with the SSR-time value. The partner's ?theme= param now wins on every fresh load (deterministic embeds, immune to stale localStorage) while the in-widget switcher keeps working for the rest of the session. - The widget's `color-scheme: light` transparency override also flipped the browser's default text color, rendering inherited-color text (e.g. SelectBankModal's institution list) dark-on-dark; set explicit per-theme default text colors on the widget body. - AnimatedModal: max-h was sm:-only, so tall panels (network selector) on narrow viewports — real phones and the widget alike — could outgrow the screen with no way to scroll back; cap at 90dvh at all breakpoints. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Resolve conflicts in KycModal, InjectedWalletContext, and StarknetContext. Co-authored-by: Cursor <cursoragent@cursor.com>
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
3 participants
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
reportClientErrorin Privy auth (Navbar), injected wallet init (InjectedWalletContext), Starknet wallet create/ensure (StarknetContext), and legacy KYC (KycModal).feature,flow,step, andstatusCodefromreportClientErrorcontext to Sentry tags for filtering and alert rules in GlitchTip.Description
Production onboarding failures (login, wallet connect/create, KYC sign/initiate/status) were mostly invisible in GlitchTip because many paths only used
console.error/ toasts and never calledreportClientError. The globalErrorBoundaryand a few swap paths were already covered; this PR closes the gap for first-time user flows.Changes
Navbar.tsxlogin()click failure; errors inuseLoginonComplete(login vs signup)InjectedWalletContext.tsxcode === 4001)StarknetContext.tsxKycModal.tsxinitiateKYCfailure (with HTTP status when present); status refresh failuresentry.client.tsfeature,flow,step,statusCodeto Sentry tags; full context still inextraTag convention (for GlitchTip filters / alerts)
feature:onboardingflow:auth|wallet|kycstep: e.g.privy-login-click,login-onComplete,signup-onComplete,injected-wallet-init,starknet-create-wallet,kyc-initiate, etc.Breaking changes: None.
Alternatives considered: Relying only on
toastMappedError/ErrorBoundary— rejected because onboarding errors are often caught and not rethrown. Server-side aggregator Sentry — separate from Noblocks client visibility.References
Testing
Environment: Noblocks local dev (
localhost:3000), browser with DevTools Network + Console.Prerequisites
NEXT_PUBLIC_SENTRY_DSNset to the Noblocks GlitchTip project DSNNEXT_PUBLIC_SENTRY_ENABLE_IN_DEV=truein.env.local, then restartnext devManual checks
onCompleteerror if possible). Confirm a GlitchTip event withfeature=onboarding,flow=auth, and the expectedstep.?injected=true(or your injected flow); reject connection → no event (4001). Simulate a real connect failure → event withflow=wallet,step=injected-wallet-init.flow=walletandstarknet-*steps.flow=kycandstatusCodetag when HTTP status is available.Automated tests: Not added; instrumentation only. Existing tests should pass unchanged.
Checklist
mainBy submitting a PR, I agree to Paycrest's Contributor Code of Conduct and Contribution Guide.
Summary by CodeRabbit
Bug Fixes
Observability / Monitoring