feat: integrate Sentry for error tracking and monitoring#17
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🤖 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/global-error.tsx`:
- Around line 7-27: Update the GlobalError component to support user recovery by
turning it into a client component (add "use client"), accept a reset: () =>
void prop in the GlobalError signature, and render a visible "Try again" button
that calls reset when clicked; keep the existing Sentry.captureException(error)
usage and also optionally display error.digest (if present) under the button for
reference, while still rendering <NextError statusCode={0} /> for the generic
message.
In `@instrumentation-client.ts`:
- Around line 7-9: The Sentry.init call currently only supplies a dsn; update
the Sentry.init invocation (the Sentry.init(...) call) to include
client-specific configuration options: add environment (e.g.,
process.env.NODE_ENV), tracesSampleRate for performance monitoring,
replaysSessionSampleRate and replaysOnErrorSampleRate for session replay
capture, and optionally integrations to customize browser integrations; set
sensible defaults (e.g., lower tracesSampleRate in production) and read
sensitive values like the DSN from environment variables (e.g.,
NEXT_PUBLIC_SENTRY_DSN) when available.
- Around line 7-9: Replace the hard-coded Sentry DSN in the Sentry.init call
with an environment variable: read the DSN from process.env.SENTRY_DSN (or
equivalent config loader), pass that value into the dsn property in Sentry.init,
and remove the literal string; also add a simple check around Sentry.init (using
the Sentry.init invocation) to only initialize when the env var is present (or
log/throw a clear error) and ensure any required env loading (e.g., dotenv) is
performed earlier in the startup path.
In `@instrumentation.ts`:
- Around line 3-11: The register function currently checks
process.env.NEXT_RUNTIME twice with two separate ifs even though the runtime is
mutually exclusive; change the second check to an else if so only one import
path runs. Update the register function (symbol: register) to use if
(process.env.NEXT_RUNTIME === "nodejs") { await
import("./sentry.server.config"); } else if (process.env.NEXT_RUNTIME ===
"edge") { await import("./sentry.edge.config"); } to make the exclusivity
explicit and avoid the redundant check.
In `@sentry.edge.config.ts`:
- Around line 8-10: Update the Sentry.init call to include production-safe,
environment-aware settings: replace the hardcoded DSN with process.env (e.g.
NEXT_PUBLIC_SENTRY_DSN) and add environment, tracesSampleRate (use a lower rate
in production, higher in dev), and any error filtering or beforeSend option to
drop expected client-side errors; locate the Sentry.init invocation and add
these options (dsn, environment, tracesSampleRate, and optional
beforeSend/errorFilter) so the edge runtime mirrors the server config patterns.
- Around line 8-10: Sentry.init currently hardcodes the DSN string; change it to
read from an environment variable (e.g. SENTRY_DSN) and pass that value into
Sentry.init({ dsn: ... }) instead of the literal; validate that SENTRY_DSN is
present (or gracefully handle its absence) and ensure the runtime/bundler
exposes the env var for the edge runtime so environment-specific DSNs are used.
In `@sentry.server.config.ts`:
- Around line 7-9: The Sentry.init call currently hardcodes the DSN string;
change it to read from an environment variable (e.g.,
process.env.NEXT_PUBLIC_SENTRY_DSN) instead of the literal string so different
environments can supply different DSNs and avoid committing the value; update
the Sentry.init({ dsn: ... }) invocation to use that env var and ensure the
project documentation/.env instructions instruct adding NEXT_PUBLIC_SENTRY_DSN
for local development and setting the variable in your deployment environment.
- Around line 7-9: Replace the bare Sentry.init({ dsn: "..." }) call by
expanding it to include production-ready options: use Sentry.init and pull the
DSN from process.env.SENTRY_DSN (fallback optional), set environment:
process.env.NODE_ENV, set tracesSampleRate to process.env.NODE_ENV ===
"production" ? 0.1 : 1.0, add sendDefaultPii: true (or false if you don't want
PII), enableLogs: true, and add an ignoreErrors array for noisy known errors
(e.g. extension URL prefixes); also ensure you do not use NEXT_PUBLIC_ prefixed
env vars in this server-side config file (sentry.server.config.ts) so secrets
remain server-only.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 7006d027-f25f-4a5d-8e2f-08e883fb053e
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (8)
.gitignoreapp/global-error.tsxinstrumentation-client.tsinstrumentation.tsnext.config.mjspackage.jsonsentry.edge.config.tssentry.server.config.ts
GabrielePicco
requested changes
May 15, 2026
Contributor
GabrielePicco
left a comment
GabrielePicco
left a comment
There was a problem hiding this comment.
Thanks!
Requests few changes, but LGTM!
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (4)
sentry.server.config.ts (2)
8-10: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winAdd production-ready Sentry configuration options.
The current initialization only sets the DSN. For production use, consider adding:
environmentto distinguish dev/staging/prod environmentstracesSampleRateto control performance monitoring overhead (recommend 0.1 for production, 1.0 for development)sendDefaultPiito explicitly control PII inclusionenableLogsfor SDK logging visibilityignoreErrorsto suppress known noise (optional)💡 Example production configuration
Sentry.init({ dsn: SENTRY_DSN, + + environment: process.env.NODE_ENV || "development", + + // Performance monitoring: 10% sampling in production, 100% in development + tracesSampleRate: process.env.NODE_ENV === "production" ? 0.1 : 1.0, + + // Include PII in events (adjust based on privacy requirements) + sendDefaultPii: true, + + // Enable SDK logs for debugging + enableLogs: true, + + // Optional: filter out known errors + // ignoreErrors: [ + // "ResizeObserver loop limit exceeded", + // ], });🤖 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 `@sentry.server.config.ts` around lines 8 - 10, Update the Sentry.init call to include production-ready options: pass environment (use process.env.NODE_ENV or NODE_ENV-like variable) and set tracesSampleRate conditionally (e.g., 1.0 for development, 0.1 for production), set sendDefaultPii explicitly (true/false per policy), enable SDK logging via enableLogs (or appropriate debug/transport option), and add ignoreErrors with an array of known/noisy error strings; modify the existing Sentry.init({ dsn: SENTRY_DSN }) invocation to include these keys and conditionally-derived values so Sentry.init and SENTRY_DSN remain the unique anchors to find the change.
6-6:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winMove SENTRY_DSN to environment variables instead of hardcoding it.
The DSN is currently hardcoded in
lib/sentry.tswith full authentication credentials, which is a security vulnerability. Update the file to load fromprocess.env.SENTRY_DSN:Example fix
- export const SENTRY_DSN = "https://81551955b403808ca0d241b04b855620@o4511348334854144.ingest.us.sentry.io/4511370863181824"; + export const SENTRY_DSN = process.env.SENTRY_DSN || "";Ensure the environment variable is set in your deployment configuration. For development, add it to your
.env.localfile (which should be.gitignored).🤖 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 `@sentry.server.config.ts` at line 6, The SENTRY_DSN constant is currently hardcoded in lib/sentry.ts; update the code to read the DSN from process.env.SENTRY_DSN instead of the hardcoded value, i.e., replace uses/imports of the hardcoded SENTRY_DSN with an exported value that reads from process.env.SENTRY_DSN (and throws or logs a clear error if missing) so sentry.server.config.ts imports the environment-backed SENTRY_DSN; also ensure deployment and local development use the SENTRY_DSN env var (add to .env.local for dev and keep it gitignored).sentry.edge.config.ts (1)
9-11: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winAdd production-ready Sentry configuration options for edge runtime.
Similar to
sentry.server.config.ts, the edge configuration should include production-ready options. The edge runtime supports the same core configuration options:💡 Example production configuration
Sentry.init({ dsn: SENTRY_DSN, + + environment: process.env.NODE_ENV || "development", + + // Performance monitoring: 10% sampling in production, 100% in development + tracesSampleRate: process.env.NODE_ENV === "production" ? 0.1 : 1.0, + + // Enable SDK logs for debugging + enableLogs: true, });Note: Some options like
sendDefaultPiior certain integrations may have limited support in edge runtime. Test thoroughly if adding advanced options.🤖 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 `@sentry.edge.config.ts` around lines 9 - 11, Update the Sentry.init(...) call in sentry.edge.config.ts to use production-ready options similar to sentry.server.config.ts: pass environment (e.g., process.env.NODE_ENV or SENTRY_ENV), release (SENTRY_RELEASE), tracesSampleRate (or tracesSampler), attachStacktrace, and a minimal beforeSend that strips sensitive data; keep integrations minimal/edge-compatible and avoid Node-only integrations. Ensure you reference Sentry.init in this file and populate options from environment variables (SENTRY_DSN, SENTRY_RELEASE, etc.), and document/test any option (like sendDefaultPii or integrations) that may not be fully supported in the edge runtime.instrumentation-client.ts (1)
8-10: 🧹 Nitpick | 🔵 Trivial | ⚡ Quick winConsider adding client-specific Sentry configuration.
The Sentry.init call lacks client-specific options for performance monitoring and session replay:
environment,tracesSampleRate,replaysSessionSampleRate, andreplaysOnErrorSampleRate.💡 Enhanced client configuration
Sentry.init({ dsn: SENTRY_DSN, + environment: process.env.NODE_ENV, + tracesSampleRate: process.env.NODE_ENV === "production" ? 0.1 : 1.0, + replaysSessionSampleRate: 0.1, + replaysOnErrorSampleRate: 1.0, });🤖 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 `@instrumentation-client.ts` around lines 8 - 10, The Sentry.init call currently only passes SENTRY_DSN; update the Sentry.init invocation to include client-specific options: pass environment (e.g. from SENTRY_ENVIRONMENT or NODE_ENV), tracesSampleRate (from SENTRY_TRACES_SAMPLE_RATE or a default like 0.1), replaysSessionSampleRate and replaysOnErrorSampleRate (from SENTRY_REPLAYS_SESSION_SAMPLE_RATE and SENTRY_REPLAYS_ON_ERROR_SAMPLE_RATE or sensible defaults) so performance monitoring and session replay are enabled; keep SENTRY_DSN and ensure values are coerced to numbers/booleans where appropriate when adding these keys to the Sentry.init call.
🤖 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 `@lib/sentry.ts`:
- Around line 1-2: Replace the hardcoded SENTRY_DSN constant by reading the
client-exposed env var NEXT_PUBLIC_SENTRY_DSN so different environments can
supply their own DSN: update the export SENTRY_DSN in lib/sentry.ts to return
process.env.NEXT_PUBLIC_SENTRY_DSN (or undefined) and ensure the three importers
(sentry.server.config.ts, sentry.edge.config.ts, instrumentation-client.ts)
continue to import the same exported SENTRY_DSN symbol without changes; also add
NEXT_PUBLIC_SENTRY_DSN to .env.example as shown in the review comment.
---
Duplicate comments:
In `@instrumentation-client.ts`:
- Around line 8-10: The Sentry.init call currently only passes SENTRY_DSN;
update the Sentry.init invocation to include client-specific options: pass
environment (e.g. from SENTRY_ENVIRONMENT or NODE_ENV), tracesSampleRate (from
SENTRY_TRACES_SAMPLE_RATE or a default like 0.1), replaysSessionSampleRate and
replaysOnErrorSampleRate (from SENTRY_REPLAYS_SESSION_SAMPLE_RATE and
SENTRY_REPLAYS_ON_ERROR_SAMPLE_RATE or sensible defaults) so performance
monitoring and session replay are enabled; keep SENTRY_DSN and ensure values are
coerced to numbers/booleans where appropriate when adding these keys to the
Sentry.init call.
In `@sentry.edge.config.ts`:
- Around line 9-11: Update the Sentry.init(...) call in sentry.edge.config.ts to
use production-ready options similar to sentry.server.config.ts: pass
environment (e.g., process.env.NODE_ENV or SENTRY_ENV), release
(SENTRY_RELEASE), tracesSampleRate (or tracesSampler), attachStacktrace, and a
minimal beforeSend that strips sensitive data; keep integrations
minimal/edge-compatible and avoid Node-only integrations. Ensure you reference
Sentry.init in this file and populate options from environment variables
(SENTRY_DSN, SENTRY_RELEASE, etc.), and document/test any option (like
sendDefaultPii or integrations) that may not be fully supported in the edge
runtime.
In `@sentry.server.config.ts`:
- Around line 8-10: Update the Sentry.init call to include production-ready
options: pass environment (use process.env.NODE_ENV or NODE_ENV-like variable)
and set tracesSampleRate conditionally (e.g., 1.0 for development, 0.1 for
production), set sendDefaultPii explicitly (true/false per policy), enable SDK
logging via enableLogs (or appropriate debug/transport option), and add
ignoreErrors with an array of known/noisy error strings; modify the existing
Sentry.init({ dsn: SENTRY_DSN }) invocation to include these keys and
conditionally-derived values so Sentry.init and SENTRY_DSN remain the unique
anchors to find the change.
- Line 6: The SENTRY_DSN constant is currently hardcoded in lib/sentry.ts;
update the code to read the DSN from process.env.SENTRY_DSN instead of the
hardcoded value, i.e., replace uses/imports of the hardcoded SENTRY_DSN with an
exported value that reads from process.env.SENTRY_DSN (and throws or logs a
clear error if missing) so sentry.server.config.ts imports the
environment-backed SENTRY_DSN; also ensure deployment and local development use
the SENTRY_DSN env var (add to .env.local for dev and keep it gitignored).
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 4fa3d89e-4d14-4359-8255-8cf353aac04e
📒 Files selected for processing (4)
instrumentation-client.tslib/sentry.tssentry.edge.config.tssentry.server.config.ts
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
2 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.
This pull request integrates Sentry error monitoring into the app. Sentry is now configured for client, server, and edge environments, enabling comprehensive error tracking and reporting. The Next.js configuration is updated to support Sentry's source map uploads and optimizations, and the necessary Sentry package is added to the project dependencies.
Sentry Integration and Configuration:
instrumentation-client.ts), server (sentry.server.config.ts), and edge (sentry.edge.config.ts) environments, each with the appropriate DSN and setup instructions. [1] [2] [3]next.config.mjsto wrap withwithSentryConfig, enabling source map uploads, logging controls, and tree-shaking for Sentry, as well as setting project and organization details. [1] [2]@sentry/nextjspackage to the project dependencies inpackage.json.Error Handling:
GlobalErrorcomponent (app/global-error.tsx) that captures exceptions with Sentry and displays a generic error page using Next.js's default error component.Instrumentation Utilities:
instrumentation.tsto register Sentry for different runtimes and expose utility functions for capturing request errors.Summary by CodeRabbit