ref(node-core): Vendor OTel rpc-metadata and drop @opentelemetry/core dependency

[msonnb]

@sentry/node-core only depended on @opentelemetry/core for the RPC metadata helpers (getRPCMetadata/setRPCMetadata/RPCType) used by the HTTP server spans integration. This vendors that single small module and drops the dependency entirely.

The vendored file is colocated with its sole consumer under integrations/http/vendored/rpcMetadata.ts, matching the pattern already used for the vendored undici instrumentation (colocated with consumer) rather than a top-level vendored/ directory, since it has exactly one caller.

With the import switched to the vendored copy, @opentelemetry/core is no longer referenced anywhere in src, so it was removed from peerDependencies, peerDependenciesMeta, devDependencies, and the README's dependency list and install commands.

ref #21674
closes #22280

[msonnb]

bugbot run

[cursor]

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.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit c56eb18. Configure here.}

[cursor]

Vendored RPC key breaks interop

High Severity

createContextKey returns a unique symbol on every call, so this vendored RPC_METADATA_KEY is not the same key as @opentelemetry/core's. Framework instrumentations (Express, Fastify, Koa, etc.) call getRPCMetadata from @opentelemetry/core and will no longer find the metadata httpServerSpansIntegration stores, so rpcMetadata.route stays unset and http.route / transaction-name updates from that path are lost for @sentry/node-core bring-your-own-OTel setups.

Additional Locations (1)

• packages/node-core/src/integrations/http/httpServerSpansIntegration.ts#L180-L183

 

^{Reviewed by Cursor Bugbot for commit c56eb18. Configure here.}

[msonnb]

this shouldn't be a problem since createContextKey calls Symbol.for under the hood. So if we keep the string exactly the same, this resolves to the same key. See https://github.com/open-telemetry/opentelemetry-js/blob/d8894cf99074d487203e1b814d9c3679019b63d3/api/src/context/context.ts#L13

[mydea]

I wonder if we need this at all? SInce we now control all of this, could we not get rid of this totally, and instead just directly set the things we need (http.route attribute I guess) directly?

[msonnb]

I wonder if we need this at all? SInce we now control all of this, could we not get rid of this totally, and instead just directly set the things we need (http.route attribute I guess) directly?

mhm so if i understand this correctly we can actually drop all the rpcMetadata paths (like here) since we set http.route directly in the framework integrations with setHttpServerSpanRouteAttribute, and never through this RPCMetadata context, right?

[mydea]

I wonder if we need this at all? SInce we now control all of this, could we not get rid of this totally, and instead just directly set the things we need (http.route attribute I guess) directly?

mhm so if i understand this correctly we can actually drop all the rpcMetadata paths (like here) since we set http.route directly in the framework integrations with setHttpServerSpanRouteAttribute, and never through this RPCMetadata context, right?

jup, but only in v11! for now we need to still set this as in theory external instrumentation could use this. I have slightly adjusted this here: #22292

[msonnb]

closing as we will just remove this in v11