ref(node): Move node-fetch instrumentation away from InstrumentBase#21778
Open
mydea wants to merge 2 commits into
Open
ref(node): Move node-fetch instrumentation away from InstrumentBase#21778mydea wants to merge 2 commits into
mydea wants to merge 2 commits into
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
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.
Reviewed by Cursor Bugbot for commit cc1a55a. Configure here.
Contributor
size-limit report 📦
|
mydea
requested review from
JPeer264 and
andreiborza
and removed request for
a team
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
Comment on lines
-27
to
-32
| breadcrumbs?: boolean; | ||
|
|
||
| /** | ||
| * If set to false, do not emit any spans. | ||
| * This will ensure that the default UndiciInstrumentation from OpenTelemetry is not setup, | ||
| * only the Sentry-specific instrumentation for breadcrumbs & trace propagation is applied. |
Contributor
There was a problem hiding this comment.
Bug: The tracePropagation: false option is ignored by the new instrumentUndici function, causing trace headers to be injected unconditionally for span instrumentation.
Severity: MEDIUM
Suggested Fix
Update the UndiciInstrumentationConfig type to include the tracePropagation option. Pass this option from the nativeNodeFetchIntegration options into instrumentUndici(). Finally, modify instrumentUndici() and its helper injectTracePropagationHeaders() to respect the tracePropagation flag and only inject headers when it is not false.
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/node-fetch/index.ts#L27-L32
Potential issue: The new undici span instrumentation does not honor the
`tracePropagation: false` option. The `instrumentUndici()` function, which handles span
instrumentation, is called without the `tracePropagation` option and has no mechanism to
receive it. As a result, its internal `injectTracePropagationHeaders()` function is
always called, leading to trace headers being unconditionally injected for outgoing
requests when spans are enabled. This is a regression from previous behavior where the
option was respected, and it contradicts the user's explicit configuration.
Also affects:
packages/node/src/integrations/node-fetch/undici-instrumentation.ts:385~411
Did we get this right? 👍 / 👎 to inform future reviews.
Comment on lines
+84
to
+86
| if (_channelSubs.length) { | ||
| return; | ||
| } |
Contributor
There was a problem hiding this comment.
Bug: In multi-client setups, only the first nativeNodeFetchIntegration configuration is respected; subsequent configurations for the integration are silently ignored.
Severity: MEDIUM
Suggested Fix
Remove the module-level singleton that makes the instrumentation idempotent with a 'first-call-wins' configuration. The integration's state should not be stored in a global, process-wide variable. Instead, configuration should be managed on a per-client basis to ensure that each Sentry client's nativeNodeFetchIntegration options are respected independently.
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/node-fetch/undici-instrumentation.ts#L84-L86
Potential issue: The `instrumentUndici()` function is designed to be idempotent, using a
module-level singleton that latches onto the configuration from the first call. In a
multi-client scenario where multiple Sentry clients are initialized in the same process
with different `nativeNodeFetchIntegration` options, the configuration for all but the
first client will be silently ignored. This 'first-call-wins' behavior can lead to
unexpected outcomes, such as trace propagation being enabled when a subsequent client
configuration intended to disable it.
Did we get this right? 👍 / 👎 to inform future reviews.
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
1 participant
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 streamlines and de-otelifies the undici instrumentation in node package.
Note that there is still a OTEL instrumentation (channel based, but still) in node-core which can be updated in a separate follow up step.
This also updates to use sentry/conventions and drop any config we hard coded so far, streamlining this. Also, unsubscribe code was removed and other things we do not need were removed.