You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: develop-docs/sdk/telemetry/scopes.mdx
+18-24Lines changed: 18 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,55 +6,49 @@ title: Scopes
6
6
This document uses key words such as "MUST", "SHOULD", and "MAY" as defined in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) to indicate requirement levels.
7
7
</Alert>
8
8
9
-
The implementation in each SDK consists of three types of scopes:
9
+
The implementation in each SDK MUST consist of three types of scopes:
10
10
11
11
- The global scope
12
12
- The isolation scope
13
13
- The current scope
14
14
15
-
Regardles of the scope type, data like tags, breadcrumbs, context, etc. can be added to each scope type by the user.
15
+
Users MUST be able to add data such as `tags`, `breadcrumbs`, and `context` to any scope, regardless of its type.
16
+
17
+
## Choosing the Right Scope
16
18
17
19
### Global Scope
18
20
19
-
The global scope acts as a global variable that stays the same for the entire execution of the application. Data applied to this scope will be applied to **all** events emitted by the SDK.
20
-
This scope is used for application-wide data like the `release`, the `environment`, etc.
21
+
The global scope functions as a persistent global variable throughout the application's execution. Any data assigned to this scope is automatically applied to **all** events emitted by the SDK.
22
+
23
+
It is typically used to store application-wide data, such as the `release`, `environment`, and similar context.
21
24
22
25
### Isolation Scope
23
26
24
-
The isolation scope holds data which is only applicable to the current request (on a server), tab (in a browser), or user (on mobile). Top-level SDK APIs like `sentry.setTag()`, `sentry.setContext()`, etc. write to the isolation scope.
27
+
The isolation scope MUST contain data specific to the current execution context: a single request (on a server), a single tab (in a browser), or a single user session (on mobile). Top-level SDK APIs, such as `sentry.setTag()` and `sentry.setContext()` MUST write to the isolation scope.
25
28
26
-
The isolation scope is stored in a context variable, threadlocal, asynclocal, or similar depending on the platform.
29
+
The isolation scope SHOULD be implemented using a context variable, thread-local storage, async-local storage, or an equivalent mechanism appropriate for the platform.
27
30
28
-
The isolation scope is forked by the SDK's integrations. Users should not need to think about isolation scopes or forking of one.
31
+
SDK integrations MUST handle the forking of isolation scopes automatically. Users MUST NOT need to manage or be concerned with the details of scope isolation or its forking process.
29
32
30
33
### Current Scope
31
34
32
-
This scope holds data for the current active span. Whenever a new span is started the current scope of the parent span is forked (read: duplicated), giving the new span all the data from the parent span and making it possible to add or mutate data that is just applied to the new span (see also "Copy-on-write").
33
-
34
-
Changing the original scope after forking does not modify the forked scope.
35
-
36
-
The current scope is stored in a context variable, thread local, async local, or similar depending on the platform.
37
-
38
-
The current scope can be forked by the end user. Either explicitly, by using `sentry.withScope()` or implicitly, by starting a new span.
35
+
The current scope MUST maintain data for the active span. When a new span is started, the current scope of the parent span is forked (i.e., duplicated), transferring all data from the parent span to the new span. This allows modifications or additions specific to the new span without affecting the parent span. This behavior aligns with a "copy-on-write" model.
39
36
40
-
### The Scope APIs
37
+
Any changes made to the current scope after forking MUST NOT impact the forked scope.
41
38
42
-
```js
43
-
...
44
-
```
39
+
The current scope SHOULD be implemented using a context variable, thread-local storage, async-local storage, or an equivalent mechanism appropriate for the platform.
45
40
46
-
### Applying the scope data to events
41
+
Users MAY fork the current scope explicitly by invoking `sentry.withScope()` or implicitly by starting a new span.
47
42
48
-
The data held by all three scope types is merged before it is applied to an event.
43
+
## Applying Scope Data to Events
49
44
50
-
This is performed in the following order:
45
+
Data from all three scope types MUST be merged in a specific order before being applied to an event. The process is as follows:
51
46
52
-
1.Data from the global scope is...
47
+
1.data from the global scope is...
53
48
2. merged with data from the isolation scope, which is...
54
49
3. merged with data from the current scope, which is ...
55
50
4. applied to the event
56
51
57
52
## Related Documents
58
53
59
-
This is a more concise version of the [Hub & Scope Refactoring](/sdk/miscellaneous/hub_and_scope_refactoring/) document. It does focus on the actual implementation and expected features.
60
-
The old document remains unchanged, and offers more historical context and migration strategies.
54
+
This document provides a concise summary of the [Hub & Scope Refactoring](/sdk/miscellaneous/hub_and_scope_refactoring/), focusing on implementation details and expected features. The original document remains unchanged, offering additional historical context and migration strategies.
0 commit comments