feat(node-experimental): Replace getCurrentHub
with getCurrentScope
#9419
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 removes
getCurrentHub()
&configureScope()
from node-experimental, and instead exposes a few new APIs:getCurrentScope()
getCurrentRootScope()
withScope()
- has the same API as before, uses OTEL under the hoodwithRootScope()
getClient()
getClient()
IMHO this API we can/should add to all SDKs, it's annoying to have to do
getCurrentHub().getClient()
anyhow. This is just a short cut and a nicer API.What is a root scope
This PR introduces the (tentative) concept of a root scope. A root scope is supposed to be the scope attached to an execution context, e.g. to a route handler:
The goal of the root scope is to make reasoning about scopes with the heavily nested scopes/contexts we have in otel easier. Since every change on the context creates a new hub & scope, you can quickly get into a scenario where it's impossible to actually get the correct scope to add stuff to.
Eventually, the idea is that the root scope is always applied to events in addition the the actual current scope. This is not yet implemented in this PR but will be done in a follow up PR. This will also streamline the breadcrumbs handling we have, as we'll be able to simply put the breadcrumbs on the root scope instead of on the root span.
The scenario we are solving is things like this:
Without this, it is basically impossible to add execution-context specific things, because the fastify otel instrumentation creates a span for each hook, which in turn creates a new context (and scope), which means that if you do this:
You'll only add this to the scope valid inside of this hook, not to the request.
For most user-land scenarios, this should not be necessary - you can still do e.g.:
To mutate the current scope. But it gives more flexibility to integrations/plugins etc.
How do we detect/set the root scope
Here is where it gets tricky. Conceptually, in most cases it is relatively clear what we want the root scope to be - the scope for the
http.server
request. However, it is not necessarily easy to find this, nor to generalize this for all environments, as some may not have requests at all.This PR takes the following approach: