-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feat(node): pass prisma instrumentation options through #18900
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
feat(node): pass prisma instrumentation options through #18900
Conversation
JPeer264
left a comment
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.
Amazing thanks a lot for the contribution. I just added one tiny test.
Also for the record. I was thinking about omitting the enabled option, but that would need extra documentation why this is omitted - so its left as is :)
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.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
| expect(PrismaInstrumentation).toHaveBeenCalledTimes(1); | ||
| expect(PrismaInstrumentation).toHaveBeenCalledWith(config); | ||
| }); | ||
| }); |
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.
Missing integration or E2E tests for feature
Low Severity · Bugbot Rules
The PR adds a new instrumentationConfig option (a feat PR) but only includes unit tests with mocked dependencies. Per the review rules: "When reviewing a feat PR, check if the PR includes at least one integration or E2E test." The existing unit tests verify mock interactions but don't test that configuration actually passes through to a real PrismaInstrumentation instance and affects behavior correctly. Flagging because the rules file explicitly requires this.
|
Just as a quick FYI. The hydrogen tests are failing - we are on it to fix them. Once they pass I'll rebase and merge :) |
| export const instrumentPrisma = generateInstrumentOnce<PrismaOptions>(INTEGRATION_NAME, options => { | ||
| return new SentryPrismaInteropInstrumentation(options); |
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.
Bug: Re-initializing prismaIntegration with new options passes the wrong object shape to setConfig, causing the new configuration to be ignored or fail.
Severity: MEDIUM
Suggested Fix
Refactor instrumentPrisma to use the three-parameter form of generateInstrumentOnce, providing an optionsCallback function. This callback should extract the instrumentationConfig from the full PrismaOptions object, ensuring that both the constructor and setConfig receive an object with the same, correct shape. This pattern is used by the GraphQL integration.
Prompt for AI Agent
Review the code at the location below. A potential bug has been identified by an AI
agent.
Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not
valid.
Location: packages/node/src/integrations/tracing/prisma.ts#L172-L173
Potential issue: The `prismaIntegration` uses a version of `generateInstrumentOnce` that
causes a type mismatch during re-initialization. On the first call, the
`SentryPrismaInteropInstrumentation` constructor correctly receives the
`instrumentationConfig` object. However, on subsequent calls with new options, the
`instrumented.setConfig()` method is called with the entire `PrismaOptions` object, not
just the nested `instrumentationConfig`. This mismatch means any updated configuration
will be ignored or could lead to runtime errors if the application hot-reloads or
re-initializes Sentry with different Prisma settings.
Did we get this right? 👍 / 👎 to inform future reviews.
This PR adds the external contributor to the CHANGELOG.md file, so that they are credited for their contribution. See #18900 Co-authored-by: JPeer264 <10677263+JPeer264@users.noreply.github.com>
Before submitting a pull request, please take a look at our
Contributing guidelines and verify:
If you've added code that should be tested, please add tests.yarn lint) & (yarn test).Closes #17181