getsentry / getsentry/sentry-javascript
Rework span start and end lifecycle hook emission
- Vorherrschende Sprache
- TypeScript
- Sterne
- 8.7k
- Forks
- 1.8k
- Ø Merge
- 1 T. 17 Std.
- Gemergte PRs (30 T.)
- 515
Beschreibung
Currently, the behaviour for `spanStart` and `spanEnd`/`afterSpanEnd` client hook event emissions is a bit inconsistent across SDKs and span types
### Sentry Spans (non-OTel path)
| Case | Span class | `spanStart` | `spanEnd` | Notes |
|---|---|---|---|---|
| **Sampled root** | `SentrySpan` | Yes | Yes (via `_onSpanEnded`) | |
| **Negatively sampled root** | `SentrySpan` (`sampled: false`) | **Yes** | **Yes** (via `_onSpanEnded`) | Hooks fire, listeners must guard themselves |
| **Sampled child** | `SentrySpan` | **Yes** | **Yes** (via `_onSpanEnded`) | |
| **Negatively sampled child** | `SentryNonRecordingSpan` | **Yes** | **No** (`end()` is no-op) | **Unpaired!** `spanStart` fires, `spanEnd` never does |
| **Ignored span** | `SentryNonRecordingSpan` | **No** (returns before `_startChildSpan`) | **No** | |
| **`onlyIfParent`**, no parent | `SentryNonRecordingSpan` | **No** (created before `createChildOrRootSpan`) | **No** | |
| **Tracing disabled** | `SentryNonRecordingSpan` | **No** (`hasSpansEnabled()` = false) | **No** | |
### OTel Spans
| Case | OTel `SamplingDecision` | Reaches processor? | `spanStart` | `spanEnd` |
|---|---|---|---|---|
| **Sampled root** | `RECORD_AND_SAMPLED` | Yes | Yes | Yes |
| **Negatively sampled root** | `NOT_RECORD` | No | No | No |
| **Sampled child** | `RECORD_AND_SAMPLED` | Yes | Yes | Yes |
| **Negatively sampled child** | `NOT_RECORD` | No | No | No |
| **Ignored span** | `NOT_RECORD` | No | No | No |
### Goals
- We need to align on the behaviour and at the very least fix the unpaired occurance of the negatively sampled child span scenario
- We simplify which actor emits the events. Ideally, only the span classes (Sentry) and span processor (OTel) emit the hooks. Though this can be challenging with the cases where we early return for ignored/no_parent_span cases.
Beitragsleitfaden
Bewertung
Dieses Issue wurde noch nicht bewertet.