diff --git a/docs/platforms/javascript/common/enriching-events/request-isolation/index.mdx b/docs/platforms/javascript/common/enriching-events/request-isolation/index.mdx new file mode 100644 index 0000000000000..bafd5765f24e1 --- /dev/null +++ b/docs/platforms/javascript/common/enriching-events/request-isolation/index.mdx @@ -0,0 +1,36 @@ +--- +title: Request Isolation +description: "Learn more about how request isolation (or process isolation) works in the Sentry SDK." +supported: + - javascript.nextjs + - javascript.node + - javascript.connect + - javascript.express + - javascript.fastify + - javascript.hapi + - javascript.koa + - javascript.nestjs + - javascript.nuxt + - javascript.solidstart + - javascript.sveltekit + - javascript.astro + - javascript.remix +notSupported: + - javascript +--- + +In server-side environments, the isolation scope automatically forks around request boundaries. This is done automatically by the SDK. As a result, each request has its own isolation scope, and data set on the isolation scope only applies to events captured during that request. + +However, there are also other times when you may want to have isolation, for example, in background jobs or when you want to isolate a specific part of your code. In these cases, you can use `Sentry.withIsolationScope()` to create a new isolation scope that's valid inside of the callback you pass to it. Learn more about using [withIsolationScope](../scopes/#using-withisolationscope). + +The following example shows how you can use `withIsolationScope` to attach data to a specific job run: + +```javascript +async function job(jobId) { + return Sentry.withIsolationScope(async () => { + // Only valid for events in this callback + Sentry.setTag("jobId", jobId); + await doSomething(); + }); +} +``` diff --git a/docs/platforms/javascript/common/enriching-events/scopes/index.mdx b/docs/platforms/javascript/common/enriching-events/scopes/index.mdx index 34ba5fa7a67e6..bc0d760424270 100644 --- a/docs/platforms/javascript/common/enriching-events/scopes/index.mdx +++ b/docs/platforms/javascript/common/enriching-events/scopes/index.mdx @@ -143,3 +143,13 @@ In the following example we use to atta The scope inside the `withScope()` callback is only valid inside of the callback. Once the callback ends, the scope will be removed and no longer applied. The inner scope is only applied to events that are captured inside of the callback. `withScope()` will clone (or fork) the current scope, so that the current scope is not modified. This allows you to more easily isolate pieces of context information to specific locations in your code or even call to briefly remove all context information. + + +## Using `withIsolationScope` + +`withIsolationScope` works fundamentally the same as `withScope`, but it will fork the isolation scope instead of the current scope. Generally, the isolation scope is meant to be forked less frequently than the current scope, and in most cases the SDK will handle this automatically for you. + +But in cases where you e.g. want to isolate a non-request process (e.g. a background job), you can use `withIsolationScope` to create a new isolation scope that is only active for the duration of the callback: + + + diff --git a/platform-includes/enriching-events/scopes/with-isolation-scope/javascript.mdx b/platform-includes/enriching-events/scopes/with-isolation-scope/javascript.mdx new file mode 100644 index 0000000000000..cd609f40519e3 --- /dev/null +++ b/platform-includes/enriching-events/scopes/with-isolation-scope/javascript.mdx @@ -0,0 +1,13 @@ +```javascript +Sentry.withIsolationScope(function () { + // This user & tag is set inside of this callback + Sentry.setUser({ id: "123" }); + Sentry.setTag("my-tag", "my value"); + + // will be tagged with my-tag="my value" & user + Sentry.captureException(new Error("my error")); +}); + +// will not be tagged with my-tag & user +Sentry.captureException(new Error("my other error")); +```