Skip to content

Conversation

@Dprof-in-tech
Copy link
Collaborator

@Dprof-in-tech Dprof-in-tech commented Dec 18, 2025

Description

comment out sentry nextjs package to test something.

References

Testing

  • This change adds test coverage for new/changed/fixed functionality

Checklist

  • I have added documentation and tests for new/changed functionality in this PR
  • All active GitHub checks for tests, formatting, and security are passing
  • The correct base branch is being used, if not main

By submitting a PR, I agree to Paycrest's Contributor Code of Conduct and Contribution Guide.

Summary by CodeRabbit

  • Chores
    • Disabled error tracking integration by default. Monitoring services are no longer active in the default application configuration.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 18, 2025

Walkthrough

The default export in next.config.mjs is changed to export the base nextConfig directly, with the withSentryConfig wrapper commented out. This disables Sentry integration at the configuration level while preserving the wrapper configuration for future re-enablement.

Changes

Cohort / File(s) Summary
Sentry integration disabled
next.config.mjs
Default export modified from withSentryConfig(nextConfig, { ... }) to nextConfig; Sentry wrapper configuration moved to block comment.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

  • Verify the export statement matches intended configuration state
  • Confirm commented Sentry configuration is preserved for future re-enablement
  • Validate no other configuration files require corresponding changes

Suggested reviewers

  • chibie
  • 5ran6

Poem

🐰 A config tweak, clean and bright,
Sentry sleeps, the export's light,
Wrapped no more, it runs so free,
Next.js defaults, as it should be! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)
Check name Status Explanation Resolution
Title check ⚠️ Warning The PR title mentions 'privy dependency' but the actual change disables Sentry configuration, not privy—creating a mismatch between title and implementation. Update the title to accurately reflect the change, such as 'Disable Sentry configuration by default' or clarify how this fixes the privy-related build error.
Description check ❓ Inconclusive The description is vague ('comment out sentry nextjs package to test something') and lacks critical context about why this change is needed or what specific issue it resolves. Provide detailed explanation of the build error being fixed, why Sentry integration must be disabled, and what testing was performed to verify the fix works.
✅ Passed checks (1 passed)
Check name Status Explanation
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch fix-build-error-on-production-privy-dependency

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

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

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (1)
next.config.mjs (1)

1-1: Unused import should be removed or documented.

The withSentryConfig import is no longer used since Sentry integration is commented out. Either remove this import to keep the code clean, or add a comment explaining it's retained for easy re-enablement.

🔎 Apply this diff if Sentry re-enablement is not planned immediately:
-import { withSentryConfig } from "@sentry/nextjs";
+// import { withSentryConfig } from "@sentry/nextjs"; // Uncomment when re-enabling Sentry
📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between eae5321 and 256a8eb.

📒 Files selected for processing (1)
  • next.config.mjs (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: build (20.x)
🔇 Additional comments (1)
next.config.mjs (1)

128-147: Review of Sentry configuration change is safe but verify client-side code exists.

Commenting out withSentryConfig disables build-time Sentry instrumentation, which is fine for memory optimization. Since the Sentry SDK gracefully handles a missing or empty DSN without runtime errors, there's no risk of method calls failing. However, if you have Sentry client initialization code (sentry.client.config.ts, instrumentation files, or direct Sentry.init calls), verify those aren't relying on build-time Sentry configuration to function correctly. Consider whether you want to also disable or conditional-guard those files when Sentry is disabled.

},
};

// Disable Sentry to save memory during builds - comment out this line and uncomment block below to re-enable
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Misleading comment - disables Sentry at runtime, not just during builds.

The comment states this saves memory "during builds," but exporting nextConfig directly disables Sentry integration entirely, including at runtime in production. This affects error tracking and monitoring in your live application, not just the build process.

If the goal is specifically to reduce build memory usage, consider using the existing LOW_MEMORY_BUILD environment variable (referenced in line 140) to disable only sourcemaps during builds, while keeping Sentry active at runtime.

🤖 Prompt for AI Agents
In next.config.mjs around line 128, the comment incorrectly says Sentry is
disabled "during builds" while exporting nextConfig actually disables Sentry at
runtime too; update the comment to clearly state that exporting nextConfig
disables Sentry integration at runtime (production) and not only during builds,
and either revert to the previous Sentry-enabled export or change the logic to
gate only build-time behavior behind the LOW_MEMORY_BUILD env var (so
sourcemaps/build memory can be reduced) while keeping Sentry middleware/config
active at runtime.

Comment on lines +128 to +129
// Disable Sentry to save memory during builds - comment out this line and uncomment block below to re-enable
export default nextConfig;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Disabling Sentry removes critical production observability.

Exporting nextConfig directly completely disables Sentry error tracking and performance monitoring in production, not just during builds. This significantly degrades your ability to debug production issues and monitor application health.

Impact:

  • No error tracking or crash reports
  • No performance monitoring
  • Loss of production observability
  • Unable to proactively identify and debug issues

Alternative approaches to consider:

  1. Use the existing LOW_MEMORY_BUILD environment variable with conditional logic rather than commenting out the entire integration
  2. Disable only sourcemaps during builds (already controlled by sourcemaps.disable in line 140)
  3. Use environment-based conditional Sentry initialization (enable only in production, disable in development/CI)
  4. Address the root cause of the build memory issue mentioned in the PR title
💡 Example: Conditional Sentry configuration based on environment
-// Disable Sentry to save memory during builds - comment out this line and uncomment block below to re-enable
-export default nextConfig;
-
-/*
-export default withSentryConfig(nextConfig, {
+// Only enable Sentry in production or when explicitly requested
+const shouldEnableSentry = process.env.NODE_ENV === 'production' && process.env.DISABLE_SENTRY !== 'true';
+
+export default shouldEnableSentry ? withSentryConfig(nextConfig, {
   org: "Paycrest",
   project: "noblocks",
   sentryUrl: process.env.SENTRY_URL,
   authToken: process.env.SENTRY_AUTH_TOKEN,
   release: "2.0.0",
   silent: !process.env.CI,
   sourcemaps: {
     disable: process.env.LOW_MEMORY_BUILD === "true",
   },
   widenClientFileUpload: true,
   tunnelRoute: "/monitoring",
   disableLogger: true,
   automaticVercelMonitors: true,
-});
-*/
+}) : nextConfig;

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents
In next.config.mjs around lines 128-129, the current direct export of nextConfig
disables Sentry entirely; restore conditional Sentry integration so production
observability remains. Update the file to initialize/wrap nextConfig with the
Sentry plugin only when not running a low-memory build (use
process.env.LOW_MEMORY_BUILD !== 'true') and/or when NODE_ENV === 'production',
otherwise export nextConfig untouched; preserve existing sourcemaps.disable
logic and any CI/dev checks so sourcemaps or other settings remain controlled
separately. Ensure the conditional preserves build-time behavior (skip Sentry
plugin during low-memory CI builds) but enables full Sentry error and
performance instrumentation in production.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant