INIT Sentry - error tracking

[Cichorek]

Summary by CodeRabbit

• New Features

  • Optional error tracking and performance monitoring for improved stability and visibility
  • Global error screen with a retry action for better in-app recovery
  • Configurable privacy/PII consent for error reports

• Documentation

  • Updated setup and deployment guides with optional Sentry configuration and privacy notes

• Chores

  • Added Sentry dependency and wiring for optional error reporting

[coderabbitai]

Warning

Rate limit exceeded

@Cichorek has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 14 minutes and 33 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

Walkthrough

Integrates Sentry into the Next.js app: adds Sentry env vars (including two new PII toggles), installs @sentry/nextjs, conditionally wraps Next config with Sentry, adds server and client instrumentation modules, and introduces a global error component; updates docs and .env example.

Changes

Cohort / File(s)	Summary
Environment example \.env\.example	Added SENTRY_SEND_DEFAULT_PII and NEXT_PUBLIC_SENTRY_SEND_DEFAULT_PII with explanatory comment; retained existing SENTRY_* entries.
Config & dependency package.json, next.config.ts	Added @sentry/nextjs dependency; exposed NEXT_PUBLIC_SENTRY_DSN in Next config and conditionally export Sentry-wrapped config via withSentryConfig (org/project/authToken, sourcemap/upload options, telemetry disabled).
Server instrumentation src/instrumentation.ts	New module exporting async register() that conditionally initializes Sentry (sendDefaultPii toggle, tracesSampleRate based on NODE_ENV) and exports onRequestError alias.
Client instrumentation src/instrumentation-client.ts	New client-side Sentry init using NEXT_PUBLIC_SENTRY_DSN, configures PII toggle and tracesSampleRate, and exports onRouterTransitionStart conditional hook.
Error UI src/app/global-error.tsx	Added GlobalError React component that captures exceptions with Sentry on mount and renders a minimal retry UI.
Documentation README.md	Documented Sentry in tech stack and features; added Optional env vars section (SENTRY_DSN, SENTRY_ORG, SENTRY_PROJECT, SENTRY_AUTH_TOKEN, SENTRY_SEND_DEFAULT_PII, NEXT_PUBLIC_SENTRY_SEND_DEFAULT_PII) and privacy note; updated deployment guidance.

Sequence Diagram

sequenceDiagram
    participant User as User
    participant Client as Next.js Client
    participant GlobalError as Global Error Handler
    participant Sentry as Sentry SDK
    participant Server as Next.js Server
    participant Instrumentation as Server Instrumentation

    rect rgba(100, 150, 200, 0.5)
    Note over Server,Instrumentation: App startup
    Server->>Instrumentation: call register()
    Instrumentation->>Sentry: initialize (if SENTRY_DSN)
    Sentry->>Sentry: configure PII, tracing rate
    end

    rect rgba(150, 100, 200, 0.5)
    Note over Client,GlobalError: Client error flow
    User->>Client: triggers error
    Client->>GlobalError: unhandled error caught
    GlobalError->>Sentry: captureException(error)
    Sentry->>Sentry: process & store error
    end

    rect rgba(200, 100, 100, 0.5)
    Note over Client,Server: Request/Server error
    Client->>Server: make request
    alt Server error
        Server->>Instrumentation: onRequestError called
        Instrumentation->>Sentry: captureRequestError
        Sentry->>Sentry: log server error
    end
    end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 I hopped through code with eager cheer,
I added Sentry, calm not fear,
Traces clean and errors caught,
A tiny button says "Try again" — taut.
Hooray, the logs now gleam so clear!

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title 'INIT Sentry - error tracking' accurately and clearly describes the main change: initializing Sentry for error tracking functionality across the application.
Merge Conflict Detection	✅ Passed	✅ No merge conflicts detected when merging into main

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch integrations/sentry

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@src/app/global-error.tsx`:
- Around line 7-23: The GlobalError component is missing the Next.js-provided
reset function so users cannot recover; update the component signature
(GlobalError) to accept a second prop reset: () => void (e.g., error: Error & {
digest?: string }; reset: () => void), keep Sentry.captureException in
useEffect, and expose the reset by either passing it into the NextError
component or rendering a visible "Try again" button that calls reset when
clicked; ensure the prop name reset is used and the button text is accessible so
users can retry rendering.

In `@src/instrumentation.ts`:
- Around line 7-11: The Sentry.init call currently hardcodes sendDefaultPii:
true which may leak PII; change Sentry.init in this file to derive
sendDefaultPii from a configuration value (e.g.
process.env.SENTRY_SEND_DEFAULT_PII or a config.get flag) and default it to
false, update the Sentry.init invocation to use that variable instead of the
literal, and ensure any consent/opt-in gating or documentation is added where
the DSN/config (dsn, tracesSampleRate) is set so enabling PII is explicit and
auditable (also add a clear env var name and comment).

🧹 Nitpick comments (1)

src/instrumentation-client.ts (1)

1-15: Consider extracting shared Sentry config to reduce duplication.

The Sentry.init options (sendDefaultPii, tracesSampleRate logic) are duplicated between instrumentation.ts and instrumentation-client.ts. A shared config object would keep them in sync.