Sentry Logging

Objective

• Add Sentry-based error and crash reporting for Attik Mobile (React Native / Expo) so field issues are visible in the same observability stack as the web app.
• Enable or restore Sentry on the Express API so server errors can be correlated with mobile and web clients where useful (shared org, tags, or tracing)—depth of backend work is a decision for the implementer alongside whoever administers the Sentry org.
• Prefer one primary vendor (Sentry) across web, mobile, and API rather than splitting mobile into Crashlytics-only or another tool, unless product explicitly revisits that tradeoff.

Background

• Web already uses @sentry/nextjs: next.config.js wraps the build with withSentryConfig; src/instrumentation.ts and src/instrumentation-client.ts initialize Sentry; sentry.server.config.ts, sentry.edge.config.ts, and src/app/global-error.tsx participate in server, edge, and client error reporting.
• Attik Mobile does not list @sentry/react-native (or other @sentry/* packages) in the scanned package.json / tree; the app uses Expo Router with main set to expo-router/entry, so early initialization matters for capturing native-layer crashes as well as JS.
• Backend ships with commented-out Sentry in src/index.ts (e.g. import './instrument.js', @sentry/node, Sentry.setupExpressErrorHandler(app), and a sample /debug-sentry route), so the Express process is not currently sending events from that entrypoint as committed.
• High-value outcomes once wired include: readable stack traces (source maps / JS bundle mapping and iOS dSYM / Android mapping uploads from CI), breadcrumbs for navigation and failures, crash-free session style metrics, and consistent user or session tags on client and server for debugging “what happened before this 500 / crash.”
• Alternatives (Datadog RUM, Firebase Crashlytics, Bugsnag) exist; the current product direction is to extend Sentry for mobile and API alignment with web.
• Decision needed: DSNs, Sentry project boundaries, release naming, EAS/GitHub Actions symbol upload steps, and PII policy for tags—coordinate with whoever owns Sentry account setup for Attik.

Scope

Attik Mobile

• Integrate @sentry/react-native (or the Expo-supported path Sentry documents for the current SDK major) with production and preview builds; wrap the root app surface so unhandled JS errors are captured.
• Configure CI (EAS Build or equivalent) to upload source maps and native debug symbols so production stacks are actionable.
• Add breadcrumbs and tags appropriate to inspector workflows (e.g. user / company / inspector identifiers) within privacy and retention constraints.

Attik Backend

• Re-enable @sentry/node in the Express pipeline: uncomment or replace patterns in src/index.ts, place request and error middleware in the correct order relative to app.js and existing handlers, and align with any instrument.js (or successor) bootstrap the team chooses.

Attik Frontend (reference only)

• Treat existing Next.js Sentry config as the convention for environment-specific DSN usage, sampling, and release strings so mobile and API do not fight web settings when sharing a project.

References

• Web: attik-frontend/next.config.js, attik-frontend/src/instrumentation.ts, attik-frontend/src/instrumentation-client.ts, attik-frontend/sentry.server.config.ts, attik-frontend/sentry.edge.config.ts, attik-frontend/src/app/global-error.tsx
• Backend: attik-backend/src/index.ts
• Mobile: attik-mobile/package.json, attik-mobile/eas/ (build / env)
• Sentry documentation: React Native / Expo, Next.js, Node Express integration