From 313a0a0e0114d08d9a39d6e4656c590214fcf257 Mon Sep 17 00:00:00 2001 From: Philipp Hofmann Date: Tue, 4 Jun 2024 10:45:40 +0200 Subject: [PATCH 1/9] rfc(decision): Mobile - Tracing Without Performance V2 --- README.md | 1 + ...-mobile-tracing-without-performance-v-2.md | 35 +++++++++++++++++++ 2 files changed, 36 insertions(+) create mode 100644 text/0136-mobile-tracing-without-performance-v-2.md diff --git a/README.md b/README.md index 70fb4df8..3dfbda9a 100644 --- a/README.md +++ b/README.md @@ -64,3 +64,4 @@ This repository contains RFCs and DACIs. Lost? - [0126-sdk-spans-aggregator](text/0126-sdk-spans-aggregator.md): SDK Spans Aggregator - [0129-video-replay-envelope](text/0129-video-replay-envelope.md): Video-based replay envelope format - [0131-pass-native-sdk-spans-to-hybrid](text/0131-pass-native-sdk-spans-to-hybrid.md): rfc(feature): Pass Native SDKs Spans to Hybrid +- [0136-mobile-tracing-without-performance-v-2](text/0136-mobile-tracing-without-performance-v-2.md): Mobile - Tracing Without Performance V2 diff --git a/text/0136-mobile-tracing-without-performance-v-2.md b/text/0136-mobile-tracing-without-performance-v-2.md new file mode 100644 index 00000000..3a50f015 --- /dev/null +++ b/text/0136-mobile-tracing-without-performance-v-2.md @@ -0,0 +1,35 @@ +- Start Date: 2024-06-04 +- RFC Type: decision +- RFC PR: https://github.com/getsentry/rfcs/pull/136 +- RFC Status: draft + +# Summary + +One paragraph explanation of the feature or document purpose. + +# Motivation + +Why are we doing this? What use cases does it support? What is the expected outcome? + +# Background + +The reason this decision or document is required. This section might not always exist. + +# Supporting Data + +[Metrics to help support your decision (if applicable).] + +# Options Considered + +If an RFC does not know yet what the options are, it can propose multiple options. The +preferred model is to propose one option and to provide alternatives. + +# Drawbacks + +Why should we not do this? What are the drawbacks of this RFC or a particular option if +multiple options are presented. + +# Unresolved questions + +- What parts of the design do you expect to resolve through this RFC? +- What issues are out of scope for this RFC but are known? From 27c44c47086dc81ab7ac6ff95b643f913fc38596 Mon Sep 17 00:00:00 2001 From: Philipp Hofmann Date: Tue, 4 Jun 2024 11:19:54 +0200 Subject: [PATCH 2/9] first version --- ...-mobile-tracing-without-performance-v-2.md | 53 +++++++++++++++---- 1 file changed, 42 insertions(+), 11 deletions(-) diff --git a/text/0136-mobile-tracing-without-performance-v-2.md b/text/0136-mobile-tracing-without-performance-v-2.md index 3a50f015..03a7212f 100644 --- a/text/0136-mobile-tracing-without-performance-v-2.md +++ b/text/0136-mobile-tracing-without-performance-v-2.md @@ -5,31 +5,62 @@ # Summary -One paragraph explanation of the feature or document purpose. +This RFC aims to find a strategy to update the so traces don’t reference hundreds of unrelated +events. # Motivation -Why are we doing this? What use cases does it support? What is the expected outcome? +On mobile, traces can have hundreds of unrelated events caused by the possibly never-changing +required for tracing without performance. This occurs mostly when users don’t have performance +enabled. # Background -The reason this decision or document is required. This section might not always exist. +In the summer of 2023, all mobile SDKs implemented [Tracing without performance](https://www.notion.so/Tracing-without-performance-efab307eb7f64e71a04f09dc72722530?pvs=21), +see also [team-sdks GH issue](https://github.com/getsentry/team-sdks/issues/5). +The goal of this endeavor was to -# Supporting Data +> always have access to a trace and span ID, add a new internal `PropagationContext` property to the +> scope, an object holding a `traceId` and `spanId` -[Metrics to help support your decision (if applicable).] +On mobile, most users interact purely with the static API, which holds a reference to a global +Hub and Scope. Therefore, mobile SDKs create a `PropagationContext` with `traceId` and `spanId` +during initialization, and these usually persist for the entire lifetime of the app. Mobile +SDKs prefer the `traceID` of transactions bound to the scope over the `PropagationContext`. So +when performance is disabled, or no transition is bound to the scope, mobile SDKs use the same +`traceId` and `spanId` for all captured events. This can lead to traces with hundreds of +unrelated events confusing users. JS addressed this recently by updating the `PropagationContext` +based on routes, see [Ensure browser traceId lifetime works as expected](https://github.com/getsentry/sentry-javascript/issues/11599). # Options Considered -If an RFC does not know yet what the options are, it can propose multiple options. The -preferred model is to propose one option and to provide alternatives. +## Option 1: Update `PropagationContext` based on screens + +Mobile SDKs base the lifetime of the `traceId` of the `PropagationContext` on screens/routes, +which is similar to a route on JavaScript. Mobile SDKs already report the screen name automatically +via `view_names` with the [app context](https://develop.sentry.dev/sdk/event-payloads/contexts/#app-context) +and use the same information for the name of screen load transactions, which the screen load +starfish module uses. Whenever the screen name changes automatically or with a yet to be defined +[manual API](https://www.notion.so/sentry/Specs-Screens-API-084d773272f24f57aeb622c07619264e), +mobile SDKs must renew the `traceId` of the `PropagationContext`. The screen load transaction +and subsequent events on the same screen must use the same `traceId`. When the app moves to the +background, mobile SDKs also update the `traceId` of the PropagationContext. + +### Pros + +1. Similar to [JavaScript]((https://github.com/getsentry/sentry-javascript/issues/11599)) updating +it based on routes, so it should be easy to implement for React-Native. +2. Works for spans first, as all spans get added to one trace per screen. + +### Cons + +1. It doesn’t work well for declarative UI frameworks as Jetpack Compose and SwiftUI for which the +SDKs can’t reliably automatically detect when apps load a new screen. # Drawbacks -Why should we not do this? What are the drawbacks of this RFC or a particular option if -multiple options are presented. +Please add drawbacks here if you can think of any. # Unresolved questions -- What parts of the design do you expect to resolve through this RFC? -- What issues are out of scope for this RFC but are known? +- None. From a68b563814f655d212fdd0c06890cfc53bf466ae Mon Sep 17 00:00:00 2001 From: Philipp Hofmann Date: Tue, 4 Jun 2024 11:24:46 +0200 Subject: [PATCH 3/9] add cons --- text/0136-mobile-tracing-without-performance-v-2.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/text/0136-mobile-tracing-without-performance-v-2.md b/text/0136-mobile-tracing-without-performance-v-2.md index 03a7212f..6ff87e10 100644 --- a/text/0136-mobile-tracing-without-performance-v-2.md +++ b/text/0136-mobile-tracing-without-performance-v-2.md @@ -54,7 +54,11 @@ it based on routes, so it should be easy to implement for React-Native. ### Cons -1. It doesn’t work well for declarative UI frameworks as Jetpack Compose and SwiftUI for which the +1. For single-screen applications such as social networks, the lifetime of a trace could still be +long, and multiple unrelated events could be mapped to one trace. +2. For applications running for a long time in the background, such as running apps, the lifetime of +a trace could still be long, and multiple unrelated events could be mapped to one trace. +3. It doesn’t work well for declarative UI frameworks as Jetpack Compose and SwiftUI for which the SDKs can’t reliably automatically detect when apps load a new screen. # Drawbacks From e3be25af32173ae969caf186c3a33a41317e28a6 Mon Sep 17 00:00:00 2001 From: Philipp Hofmann Date: Wed, 5 Jun 2024 15:06:44 +0200 Subject: [PATCH 4/9] Update text/0136-mobile-tracing-without-performance-v-2.md Co-authored-by: Karl Heinz Struggl --- text/0136-mobile-tracing-without-performance-v-2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0136-mobile-tracing-without-performance-v-2.md b/text/0136-mobile-tracing-without-performance-v-2.md index 6ff87e10..d0d198be 100644 --- a/text/0136-mobile-tracing-without-performance-v-2.md +++ b/text/0136-mobile-tracing-without-performance-v-2.md @@ -11,7 +11,7 @@ events. # Motivation On mobile, traces can have hundreds of unrelated events caused by the possibly never-changing -required for tracing without performance. This occurs mostly when users don’t have performance +`traceId` required for tracing without performance. This occurs mostly when users don’t have performance enabled. # Background From 3a70e7b8586df9f8ed3ed12a3af844dd4813260f Mon Sep 17 00:00:00 2001 From: Philipp Hofmann Date: Thu, 6 Jun 2024 16:39:34 +0200 Subject: [PATCH 5/9] add session logic --- text/0136-mobile-tracing-without-performance-v-2.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/text/0136-mobile-tracing-without-performance-v-2.md b/text/0136-mobile-tracing-without-performance-v-2.md index d0d198be..9bd44303 100644 --- a/text/0136-mobile-tracing-without-performance-v-2.md +++ b/text/0136-mobile-tracing-without-performance-v-2.md @@ -44,7 +44,11 @@ starfish module uses. Whenever the screen name changes automatically or with a y [manual API](https://www.notion.so/sentry/Specs-Screens-API-084d773272f24f57aeb622c07619264e), mobile SDKs must renew the `traceId` of the `PropagationContext`. The screen load transaction and subsequent events on the same screen must use the same `traceId`. When the app moves to the -background, mobile SDKs also update the `traceId` of the PropagationContext. +foreground after being in the background for longer than 30 seconds, which is the same approach +mobile SDKs use for determining the end of a session, mobile SDKs renew the `traceId` of the +PropagationContext. If the app stays in the background for shorter or equal to 30 seconds, +mobile SDKs must not renew the `traceId` of the PropagationContext when the app moves again to +the foreground. ### Pros From 9c252cce888884ac951bf29f29bc82aa779c8f4d Mon Sep 17 00:00:00 2001 From: Philipp Hofmann Date: Mon, 10 Jun 2024 08:21:24 +0200 Subject: [PATCH 6/9] Update text/0136-mobile-tracing-without-performance-v-2.md Co-authored-by: Markus Hintersteiner --- text/0136-mobile-tracing-without-performance-v-2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0136-mobile-tracing-without-performance-v-2.md b/text/0136-mobile-tracing-without-performance-v-2.md index 9bd44303..4b3e1d98 100644 --- a/text/0136-mobile-tracing-without-performance-v-2.md +++ b/text/0136-mobile-tracing-without-performance-v-2.md @@ -5,7 +5,7 @@ # Summary -This RFC aims to find a strategy to update the so traces don’t reference hundreds of unrelated +This RFC aims to find a strategy to define a better lifetime for traces so they don’t reference hundreds of unrelated events. # Motivation From fddeeaa2e6a7185b0b88a4579574938bd8701fae Mon Sep 17 00:00:00 2001 From: Philipp Hofmann Date: Mon, 10 Jun 2024 08:22:22 +0200 Subject: [PATCH 7/9] Update text/0136-mobile-tracing-without-performance-v-2.md Co-authored-by: Roman Zavarnitsyn --- text/0136-mobile-tracing-without-performance-v-2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0136-mobile-tracing-without-performance-v-2.md b/text/0136-mobile-tracing-without-performance-v-2.md index 4b3e1d98..259e3004 100644 --- a/text/0136-mobile-tracing-without-performance-v-2.md +++ b/text/0136-mobile-tracing-without-performance-v-2.md @@ -27,7 +27,7 @@ On mobile, most users interact purely with the static API, which holds a referen Hub and Scope. Therefore, mobile SDKs create a `PropagationContext` with `traceId` and `spanId` during initialization, and these usually persist for the entire lifetime of the app. Mobile SDKs prefer the `traceID` of transactions bound to the scope over the `PropagationContext`. So -when performance is disabled, or no transition is bound to the scope, mobile SDKs use the same +when performance is disabled, or no transaction is bound to the scope, mobile SDKs use the same `traceId` and `spanId` for all captured events. This can lead to traces with hundreds of unrelated events confusing users. JS addressed this recently by updating the `PropagationContext` based on routes, see [Ensure browser traceId lifetime works as expected](https://github.com/getsentry/sentry-javascript/issues/11599). From 764196a99a1516b6b88a26383fd537b4d72d5d8e Mon Sep 17 00:00:00 2001 From: Philipp Hofmann Date: Mon, 10 Jun 2024 08:34:25 +0200 Subject: [PATCH 8/9] spans across screens --- text/0136-mobile-tracing-without-performance-v-2.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/text/0136-mobile-tracing-without-performance-v-2.md b/text/0136-mobile-tracing-without-performance-v-2.md index 259e3004..1217417e 100644 --- a/text/0136-mobile-tracing-without-performance-v-2.md +++ b/text/0136-mobile-tracing-without-performance-v-2.md @@ -48,7 +48,9 @@ foreground after being in the background for longer than 30 seconds, which is th mobile SDKs use for determining the end of a session, mobile SDKs renew the `traceId` of the PropagationContext. If the app stays in the background for shorter or equal to 30 seconds, mobile SDKs must not renew the `traceId` of the PropagationContext when the app moves again to -the foreground. +the foreground. When a span starts, SDKs should use the traceID on the PropagationContext, but +SDKs make an exception to this rule to map all spans related to a screen/route to the same traceID. +For example, when a span leads to a new screen, SDKs should use the traceID of the new screen. ### Pros From cd840ebdb3bf08cb190c132b175bf424c02f8014 Mon Sep 17 00:00:00 2001 From: Philipp Hofmann Date: Mon, 10 Jun 2024 08:36:19 +0200 Subject: [PATCH 9/9] add route to the title --- text/0136-mobile-tracing-without-performance-v-2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0136-mobile-tracing-without-performance-v-2.md b/text/0136-mobile-tracing-without-performance-v-2.md index 1217417e..d421954c 100644 --- a/text/0136-mobile-tracing-without-performance-v-2.md +++ b/text/0136-mobile-tracing-without-performance-v-2.md @@ -34,7 +34,7 @@ based on routes, see [Ensure browser traceId lifetime works as expected](https:/ # Options Considered -## Option 1: Update `PropagationContext` based on screens +## Option 1: Update `PropagationContext` based on screens/routes Mobile SDKs base the lifetime of the `traceId` of the `PropagationContext` on screens/routes, which is similar to a route on JavaScript. Mobile SDKs already report the screen name automatically