feat: integrate Sentry for error tracking and performance monitoring

[ifaouibadi]

• Added Sentry for error handling and performance monitoring across the application.
• Updated the main application entry point to include Sentry's ErrorBoundary for improved error management.
• Wrapped route handling with Sentry's tracking functionality to capture route changes and errors.
• Introduced a new instrument.ts file to initialize Sentry with necessary configurations.
• Updated package.json and package-lock.json to include Sentry dependencies.

---

Note

Medium Risk
Adds third-party telemetry (Sentry) with sendDefaultPii enabled and introduces new build-time behavior (hidden sourcemaps + Sentry Vite plugin), which could affect privacy expectations and release/build pipelines if misconfigured.

Overview
Integrates Sentry across the app for error tracking and performance monitoring, including route-aware instrumentation via Sentry.wrapUseRoutes and a top-level Sentry.ErrorBoundary with dialog support.

Adds src/instrument.ts to initialize Sentry (DSN/env/release, tracing + replay settings) and wires it into startup via main.tsx. Updates Vite build config to generate hidden sourcemaps and run @sentry/vite-plugin (using SENTRY_ORG/SENTRY_PROJECT/SENTRY_AUTH_TOKEN) and adds the new Sentry dependencies to package.json/package-lock.json.

^{Written by Cursor Bugbot for commit da04179. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 5 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Sentry initialization runs after other modules load

Medium Severity

The import './instrument' (which calls Sentry.init()) is positioned at line 17, after 15 other imports including local modules like ./App, ./api/generated, ./config, and ./i18n. ES modules execute in declaration order, so Sentry.init() runs only after all preceding modules are fully evaluated. Any errors thrown during initialization of those modules won't be captured by Sentry. Sentry's docs explicitly state the instrument file must be imported before any other imports in the entry point.

 

[cursor]

100% trace sampling rate unsuitable for production

Medium Severity

tracesSampleRate: 1.0 sends 100% of performance transactions to Sentry for every user, page load, and navigation. Sentry's documentation explicitly recommends adjusting this value in production. This adds non-trivial overhead to every operation and can lead to significant cost at scale. Since no environment-based conditioning is applied, this rate applies equally in production.

 

[cursor]

Inner ErrorBoundary swallows errors before Sentry captures them

Medium Severity

The existing ErrorBoundary (line 50) wraps App and AeSdkProvider and is nested inside Sentry.ErrorBoundary (line 38). React error boundaries catch errors only within their subtree — the inner boundary catches rendering errors from the main app first, preventing them from propagating to the outer Sentry.ErrorBoundary. Since the inner ErrorBoundary doesn't call Sentry.captureException, most React rendering errors will go unreported to Sentry.

Additional Locations (1)

• src/main.tsx#L49-L54

 

[cursor]

PII collection enabled in crypto application

Medium Severity

sendDefaultPii: true enables automatic collection and transmission of personally identifiable information (IP addresses, cookies, user data) to Sentry's servers. For a crypto/social application handling wallet addresses and financial data, this raises significant privacy concerns. A prior Sentry security advisory (GHSA-6465-jgvq-jhgp) demonstrated that sensitive HTTP headers can be inadvertently leaked when this flag is enabled.

 

[cursor]

Build-only Sentry plugin listed in production dependencies

Low Severity

@sentry/vite-plugin is a build-time tool placed in dependencies instead of devDependencies. This package pulls in @sentry/cli with native platform binaries and post-install scripts. It's only used in vite.config.ts during builds, never at runtime. Including it in dependencies unnecessarily bloats production installs, especially for the Docker-based SSR deployment this project uses.