ref(opentelemetry): Remove wrapContextManager export#22586
Conversation
Instead, the context manager accepts the async local storage instance now, so we can also use this in vercel-edge. this will eventually go away/move to server-utils likely so we can revisit this in a follow up.
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 3f7d8fa. Configure here.
|
|
||
| export { setupEventContextTrace } from './setupEventContextTrace'; | ||
|
|
||
| // eslint-disable-next-line typescript/no-deprecated |
There was a problem hiding this comment.
Public API removed without migration docs
Medium Severity
wrapContextManagerClass is removed from the public @sentry/opentelemetry surface. That is a breaking public API removal. It was marked deprecated, but MIGRATION.md does not list this removal under @sentry/opentelemetry, and the package README still tells users they can use wrapContextManagerClass for a custom base. Flagged because the PR review rules call out public API removals and breaking changes without proper notices.
Triggered by project rule: PR Review Guidelines for Cursor Bot
Reviewed by Cursor Bugbot for commit 3f7d8fa. Configure here.
There was a problem hiding this comment.
This was already deprecated so feels minor, tbh.
There was a problem hiding this comment.
Oh, actually, I take that back. Looking a bit more closely, packages/opentelemetry/README.md says "5. Register the Sentry context manager (SentryAsyncLocalStorageContextManager, or wrapContextManagerClass for a custom base)", which is now impossible to follow, so there's definitely some docs updates to be had here.
So, probably want to update that, and add this to the @sentry/opentelemetry "removals" section in MIGRATION.md.
Also, tangential/unrelated, but noticed while looking in there, it says SentryPropagator was removed, but it seems to still be exported and used in packages/vercel-edge/src/sdk.ts?
isaacs
left a comment
There was a problem hiding this comment.
I think hardening the _bindEventEmitter() checks would be good, and it's worth considering the ordering of precedence in the ALS argument passed in.
Also, maybe this is fine since it's just a stub and explicitly warns that it doesn't do anything, but I notice that the SentryAsyncLocalStorageContextManager has more functions now, and the stub at packages/opentelemetry/src/index.browser.ts doesn't implement them. Could be good to put some no-ops on it.
| (getAsyncContextStrategy(getMainCarrier()).getTracingChannelBinding?.() | ||
| ?.asyncLocalStorage as AsyncLocalStorage<Context>) ?? new AsyncLocalStorage<Context>(); | ||
| ?.asyncLocalStorage as AsyncLocalStorage<Context>) ?? | ||
| (asyncLocalStorage || new AsyncLocalStorage()); |
There was a problem hiding this comment.
If I'm reading this right, it'll only use the passed-in ALS if there isn't already an asyncLocalStorage on the ACS.
It's higher priority than creating a new one, but shouldn't it use the explicitly provided value as the highest priority?
|
|
||
| // We use this instead of instanceof EventEmitter to make sure this also works in non-Node.js environments (e.g. vercel-edge) | ||
| function isEventEmitter(target: unknown): target is EventEmitter { | ||
| return typeof target === 'object' && target !== null && 'on' in target; |
There was a problem hiding this comment.
This feels pretty loose. Works for vercel-edge, but I'd be worried about it in other scenarios, where eg { on: true } would blow up.
| return typeof target === 'object' && target !== null && 'on' in target; | |
| return typeof target === 'object' && target !== null && 'on' in target && typeof target.on === 'function'; |
There was a problem hiding this comment.
Oh, all the moreso because then later we guard the ADD_LISTENER_METHODS with === undefined, not typeof ... === 'function', so letting a non-function through here could be pretty bad. Wasn't an issue when it was an instanceof check, but maybe the undefined check on line 132 should also be hardened into a function type check?
It'd be good to add a bind() test with { on: true } and Object.freeze({ on() {} }) just to ensure that it doesn't blow up on weird values.
|
|
||
| export { setupEventContextTrace } from './setupEventContextTrace'; | ||
|
|
||
| // eslint-disable-next-line typescript/no-deprecated |
There was a problem hiding this comment.
This was already deprecated so feels minor, tbh.
| import { AsyncLocalStorage } from 'node:async_hooks'; | ||
| import { EventEmitter } from 'node:events'; | ||
| import type { AsyncLocalStorageLookup } from './contextManager'; | ||
| import type { EventEmitter } from 'node:events'; |
There was a problem hiding this comment.
Ah, nice, fixed the clanker objection.
| if (!MaybeGlobalAsyncLocalStorageConstructor) { | ||
| DEBUG_BUILD && | ||
| debug.warn( | ||
| "Tried to register AsyncLocalStorage async context strategy in a runtime that doesn't support AsyncLocalStorage.", |
There was a problem hiding this comment.
It looks like this method is a copy of escapeNextjsTracing from packages/nextjs/src/common/utils/tracingUtils.ts, but I think the error message might be inaccurate here? At least, it feels like those should maybe be consolidated in some way?
|
|
||
| export { setupEventContextTrace } from './setupEventContextTrace'; | ||
|
|
||
| // eslint-disable-next-line typescript/no-deprecated |
There was a problem hiding this comment.
Oh, actually, I take that back. Looking a bit more closely, packages/opentelemetry/README.md says "5. Register the Sentry context manager (SentryAsyncLocalStorageContextManager, or wrapContextManagerClass for a custom base)", which is now impossible to follow, so there's definitely some docs updates to be had here.
So, probably want to update that, and add this to the @sentry/opentelemetry "removals" section in MIGRATION.md.
Also, tangential/unrelated, but noticed while looking in there, it says SentryPropagator was removed, but it seems to still be exported and used in packages/vercel-edge/src/sdk.ts?
| @@ -1,8 +1,7 @@ | |||
| export * from './exports'; | |||
|
|
|||
| // Node-specific exports | |||
There was a problem hiding this comment.
Aren't these no longer node-specific, since they're used on vercel-edge?


Instead, the context manager accepts the async local storage instance now, so we can also use this in vercel-edge. this will eventually go away/move to server-utils likely so we can revisit this in a follow up.
This also changes the manager slightly to not check for event emitter instance, as this does not work in vercel-edge, but look at the shape instead.