Besides contexts being applied directly in event processors, we need to transform contexts set onto scopes to segment span attributes. For example, when our SDK calls scope.setContext() or Sentry.setContext().
I suggest we do this in applyScopeToSegmentSpan in captureSpan. I gave this a try in the PoC implementation, though it still includes flat-mapping arbitrary context keys. This, we'll not do for now (see below). However, there are alternatives, like registering a client.on('processSegmentSpan', ...) hook in the respective call sites and adding the attribute there directly. The advantage is co-location, the trade off un-tree-shakeable code.
Note: there are some attributes missing from Sentry-conventions which we'll need to add there as well.
Explicitly out of scope:
- Arbitrary context keys or sub objects set by users. We only transform what our SDK (+integrations) sets. User-set contexts are out of scope for now. This also applies to sub-keys set on known contexts. For example:
contexts.app.version is known and converted to a segment span attribute. contexts.app.user-bought-dlc is not known and hence not converted. Neither is contexts.dogs.awesome.
- Setting these attributes on child spans
setContext calls:
- packages/angular/src/sdk.ts
- packages/aws-serverless/src/sdk.ts (2x)
- packages/browser/src/profiling/startProfileForSpan.ts
- packages/browser/src/profiling/UIProfiler.ts (3x)
- packages/bun/src/integrations/bunserver.ts
- packages/cloudflare/src/scope-utils.ts (2x)
- packages/core/src/trpc.ts
- packages/core/src/integrations/supabase.ts
- packages/deno/src/wrap-deno-request-handler.ts
- packages/google-cloud-serverless/src/gcpfunction/cloud_events.ts
- packages/google-cloud-serverless/src/gcpfunction/events.ts
- packages/node-core/src/utils/ensureIsWrapped.ts
- packages/profiling-node/src/integration.ts (3x)
- packages/react/src/redux.ts
- packages/react/src/sdk.ts
- packages/vue/src/pinia.ts
Besides contexts being applied directly in event processors, we need to transform contexts set onto scopes to segment span attributes. For example, when our SDK calls
scope.setContext()orSentry.setContext().I suggest we do this in
applyScopeToSegmentSpanincaptureSpan. I gave this a try in the PoC implementation, though it still includes flat-mapping arbitrary context keys. This, we'll not do for now (see below). However, there are alternatives, like registering aclient.on('processSegmentSpan', ...)hook in the respective call sites and adding the attribute there directly. The advantage is co-location, the trade off un-tree-shakeable code.Note: there are some attributes missing from Sentry-conventions which we'll need to add there as well.
Explicitly out of scope:
contexts.app.versionis known and converted to a segment span attribute.contexts.app.user-bought-dlcis not known and hence not converted. Neither iscontexts.dogs.awesome.setContextcalls: