-
-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update and fix Sentry and Algolia Search #1060
Update and fix Sentry and Algolia Search #1060
Conversation
@NiallJoeMaher is attempting to deploy a commit to the Codú Team on Vercel. A member of the Team first needs to authorize it. |
WalkthroughThis pull request introduces several enhancements to the search functionality within a Next.js application, particularly in the Changes
Possibly related PRs
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (1)
instrumentation.ts (1)
6-26
: LGTM with a minor suggestionThe
register
function structure looks good. It correctly separates the initialization for different runtimes.Consider adding a default case to handle situations where
NEXT_RUNTIME
is neither "nodejs" nor "edge":export function register() { switch (process.env.NEXT_RUNTIME) { case "nodejs": // Node.js initialization break; case "edge": // Edge initialization break; default: console.warn(`Unexpected NEXT_RUNTIME value: ${process.env.NEXT_RUNTIME}`); } }This approach provides better error handling and logging for unexpected runtime environments.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (3)
package-lock.json
is excluded by!**/package-lock.json
,!**/*.json
package.json
is excluded by!**/*.json
tsconfig.json
is excluded by!**/*.json
📒 Files selected for processing (7)
- components/ui/Search.tsx (2 hunks)
- instrumentation.ts (1 hunks)
- next-env.d.ts (1 hunks)
- next.config.js (1 hunks)
- sentry.client.config.ts (1 hunks)
- sentry.edge.config.ts (0 hunks)
- sentry.server.config.ts (0 hunks)
💤 Files with no reviewable changes (2)
- sentry.edge.config.ts
- sentry.server.config.ts
✅ Files skipped from review due to trivial changes (1)
- next-env.d.ts
🔇 Additional comments (6)
sentry.client.config.ts (1)
Line range hint
22-26
: LGTM! Verify Sentry documentation for API changes.The change from
new Sentry.Replay({...})
toSentry.replayIntegration({...})
appears to address the breaking changes mentioned in the PR objectives. This update likely reflects recent changes in the Sentry library's API.To ensure this change aligns with Sentry's latest recommendations:
- Please verify this update against Sentry's official upgrade guide or release notes for the version you're updating to.
- Confirm that all necessary changes related to this API update have been implemented.
Would you like me to search for and provide links to the relevant Sentry documentation regarding this API change?
next.config.js (3)
Line range hint
1-56
: Summary: Sentry updates implemented, Algolia changes not foundThe changes in this file align well with the PR objective of updating Sentry:
- An experimental instrumentation hook has been added, which may be related to Sentry monitoring.
- The Sentry configuration in the module exports has been restructured for better readability.
However, I couldn't find any changes related to Algolia Search in this file.
To ensure we haven't missed any Algolia-related changes, let's search for them:
#!/bin/bash # Check for Algolia-related code echo "Searching for Algolia-related code:" rg --type js "algolia" -iCould you please clarify where the Algolia Search updates mentioned in the PR description have been implemented? Are they in other files not included in this review?
51-56
: Approve: Improved Sentry configuration structureThe restructuring of the
withSentryConfig
call improves code readability while maintaining the same functionality. All Sentry options are now consolidated into a single object, which is a cleaner approach.Let's verify that all necessary Sentry options are included and that there are no unused imports:
#!/bin/bash # Check for Sentry-related imports and configurations echo "Checking Sentry-related code:" rg --type js "(@sentry/nextjs|withSentryConfig)" -A 10
42-44
: Approve with caution: New experimental feature addedThe addition of
instrumentationHook: true
under theexperimental
config is likely related to the Sentry update mentioned in the PR objectives. This feature can be useful for monitoring and debugging server-side code.However, please note:
- Experimental features in Next.js may not be stable for production use.
- It's recommended to document why this feature was enabled, perhaps in a comment above this section.
To ensure this feature is used correctly, let's check for any instrumentation files:
✅ Verification successful
Instrumentation setup verified successfully
The addition of
instrumentationHook: true
innext.config.js
aligns with the existing Sentry configuration across the codebase. All necessary instrumentation files and Sentry initializations are properly in place.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for instrumentation files echo "Searching for instrumentation files:" fd --type f "(instrumentation|sentry).+(js|ts)" --exec echo "Found: {}"Length of output: 315
Script:
#!/bin/bash # Corrected script to search for Sentry-related instrumentation code echo "Searching for Sentry-related instrumentation in JavaScript and TypeScript files:" rg --type js --type ts '(@sentry/nextjs|withSentryConfig)' -A 10Length of output: 10883
components/ui/Search.tsx (2)
22-22
: Verify the correctness of the AlgolialiteClient
importThe import statement has been updated to use
{ liteClient as algoliasearch }
from"algoliasearch/lite"
. Please confirm thatliteClient
is the correct named export in the updated Algolia SDK version and that it functions as intended throughout the codebase.
117-117
: Limiting search results to six items is appropriateThe addition of
hitsPerPage: 6
in the Algolia query parameters effectively limits the number of search results to six per query, enhancing user experience by providing a manageable number of results.
import * as Sentry from "@sentry/nextjs"; | ||
|
||
const SENTRY_DSN = process.env.SENTRY_DSN || process.env.NEXT_PUBLIC_SENTRY_DSN; | ||
const SENTRY_ENVIRONMENT = process.env.SENTRY_ENVIRONMENT; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Consider improving environment variable handling
The current implementation has a few potential issues:
- Using both
SENTRY_DSN
andNEXT_PUBLIC_SENTRY_DSN
might lead to confusion. Consider using only one of them consistently. SENTRY_ENVIRONMENT
is not checked for existence, which might lead to undefined behavior if the environment variable is not set.
Consider refactoring the environment variable handling as follows:
import * as Sentry from "@sentry/nextjs";
const SENTRY_DSN = process.env.NEXT_PUBLIC_SENTRY_DSN;
const SENTRY_ENVIRONMENT = process.env.SENTRY_ENVIRONMENT || 'development';
if (!SENTRY_DSN) {
console.warn('NEXT_PUBLIC_SENTRY_DSN is not set. Sentry will not be initialized.');
}
This approach:
- Uses only
NEXT_PUBLIC_SENTRY_DSN
for consistency - Provides a default value for
SENTRY_ENVIRONMENT
- Adds a warning if
SENTRY_DSN
is not set
if (process.env.NEXT_RUNTIME === "nodejs") { | ||
// this is your Sentry.init call from `sentry.server.config.js|ts` | ||
Sentry.init({ | ||
dsn: SENTRY_DSN, | ||
// Adjust this value in production, or use tracesSampler for greater control | ||
tracesSampleRate: 1, | ||
environment: SENTRY_ENVIRONMENT, | ||
}); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Improve Sentry initialization for Node.js runtime
The Sentry initialization for Node.js looks generally correct, but there are a few points to consider:
- Setting
tracesSampleRate
to 1 might be too high for production, as it samples 100% of transactions. - There's no error handling if
SENTRY_DSN
is undefined.
Consider refactoring the Node.js initialization as follows:
if (process.env.NEXT_RUNTIME === "nodejs") {
if (SENTRY_DSN) {
Sentry.init({
dsn: SENTRY_DSN,
tracesSampleRate: process.env.NODE_ENV === 'production' ? 0.1 : 1,
environment: SENTRY_ENVIRONMENT,
});
} else {
console.warn('Sentry DSN not provided. Skipping Sentry initialization for Node.js runtime.');
}
}
This approach:
- Adjusts
tracesSampleRate
based on the environment - Adds error handling for missing
SENTRY_DSN
- Uses the
SENTRY_ENVIRONMENT
variable we defined earlier
if (process.env.NEXT_RUNTIME === "edge") { | ||
Sentry.init({ | ||
dsn: SENTRY_DSN, | ||
// Adjust this value in production, or use tracesSampler for greater control | ||
tracesSampleRate: 1, | ||
environment: SENTRY_ENVIRONMENT, | ||
}); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Refactor Edge runtime initialization to reduce duplication
The Sentry initialization for Edge runtime is identical to the Node.js runtime, which leads to code duplication and the same potential issues we identified earlier.
Consider refactoring to reduce duplication and improve both initializations:
function initSentry(runtime: string) {
if (SENTRY_DSN) {
Sentry.init({
dsn: SENTRY_DSN,
tracesSampleRate: process.env.NODE_ENV === 'production' ? 0.1 : 1,
environment: SENTRY_ENVIRONMENT,
});
} else {
console.warn(`Sentry DSN not provided. Skipping Sentry initialization for ${runtime} runtime.`);
}
}
export function register() {
switch (process.env.NEXT_RUNTIME) {
case "nodejs":
initSentry("Node.js");
break;
case "edge":
initSentry("Edge");
break;
default:
console.warn(`Unexpected NEXT_RUNTIME value: ${process.env.NEXT_RUNTIME}`);
}
}
This refactored version:
- Reduces code duplication
- Improves error handling
- Adjusts
tracesSampleRate
based on the environment - Provides more informative logging
✨ Codu Pull Request 💻
Update and fix Sentry and Algolia Search
Pull Request details