Sentry logging: Attik Mobile and Express backend (aligned with web)

Objective

• Give Attik Mobile the same class of crash and error visibility the web app already gets from Sentry: JS and native-layer failures, readable stack traces after release builds, and enough context (breadcrumbs, user/session tagging) to debug production issues quickly.
• Optionally align the Express API with the same Sentry project or org so mobile-reported errors can be correlated with server-side failures (distributed tracing / shared tags)—exact depth is a decision for the implementer and whoever owns the Sentry org.
• Keep one observability home for cross-platform debugging instead of splitting mobile crashes into a separate vendor by default.

Background

• Web (Next.js) already integrates Sentry via @sentry/nextjs: next.config.js uses withSentryConfig, src/instrumentation.ts and src/instrumentation-client.ts load Sentry, and sentry.server.config.ts, sentry.edge.config.ts, and src/app/global-error.tsx participate in server/edge/client error capture.
• Attik Mobile (attik-mobile) has no @sentry dependencies or initialization in the scanned tree; Expo Router entry is expo-router/entry from package.json, so early bootstrap choices matter for native crash capture.
• Backend (attik-backend) has commented-out Sentry wiring in src/index.ts (e.g. import './instrument.js', @sentry/node, Sentry.setupExpressErrorHandler(app), and a sample /debug-sentry route), so server-side Sentry is not active in the current entrypoint as committed.
• Useful outcomes from a full setup typically include: native + JS crash reporting, source maps (JS) and debug symbols (iOS dSYM / Android mapping files) uploaded from CI, root App (or equivalent) wrapping for unhandled JS errors, breadcrumbs for navigation and failures, and consistent user or session tags across client and server if backend Sentry is enabled.
• Decision needed: who configures DSNs, org/project boundaries, release naming, and EAS/GitHub Actions steps for symbol uploads; coordinate with whoever administers Attik’s Sentry account.

Scope

Attik Mobile

• Add and configure @sentry/react-native (or current Expo-supported equivalent recommended by Sentry) so production and preview builds report errors; initialize as early as practical in the app lifecycle to maximize native crash capture.
• Wire release/build identifiers and source map / symbol upload in CI (EAS Build hooks or documented pipeline steps) so stack traces are readable.
• Set tags (e.g. user id, company id, inspector id) consistent with privacy and retention policies; align naming with web if both report to the same org.

Attik Backend

• Revisit src/index.ts (and app.js / central Express setup if error middleware belongs there) to enable @sentry/node request and error handlers in the correct order relative to existing middleware.
• Restore or replace any instrument.js (or equivalent) pattern the team standardizes on; today the import is commented next to Sentry.

Attik Frontend (reference only)

• Use existing Next.js Sentry files as the pattern for DSN handling, environment splits, and release naming—mobile and backend should not invent conflicting conventions if they share one Sentry 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 (entry / Expo scripts), EAS build configuration under attik-mobile/eas/ if present
• Sentry docs: React Native / Expo SDK, Next.js, and Node (@sentry/node) Express integration