From 61b6c134ba6c4d28e7679a3e6a035522b61fc346 Mon Sep 17 00:00:00 2001 From: Daniel Szoke Date: Tue, 4 Feb 2025 17:11:06 +0100 Subject: [PATCH] docs(sample_rand): Handling invalid incoming `sample_rand` Document how to handle an invalid incoming `sentry-sample_rand` value. Closes #12557 --- develop-docs/sdk/telemetry/traces/index.mdx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/develop-docs/sdk/telemetry/traces/index.mdx b/develop-docs/sdk/telemetry/traces/index.mdx index c7434c8e1df3c1..de8b51d4432995 100644 --- a/develop-docs/sdk/telemetry/traces/index.mdx +++ b/develop-docs/sdk/telemetry/traces/index.mdx @@ -235,7 +235,8 @@ The random value (`sample_rand`) is set according to the following rules: 1. It is _recommended_ to generate the random number deterministically using the trace ID as seed or source of randomness (make sure to do this atomically so multiple threads accessing the same random instance don't mix their seeds). The exact method by which the random number is created is implementation-defined and may vary between SDK implementations. 1. The `sample_rand` is part of the DSC (Dynamic Sampling Context) and as with other values on the `baggage` header, the `sample_rand` value from the current execution context should be propagated to downstream SDKs. It should also be sent to other system as part of the `baggage` header if Performance is disabled and sampling decision is deferred. 1. On incoming traces, an SDK takes the incoming `sentry-sample_rand` value in the `baggage` header and uses it for the rest of the current execution context (for example, request) by storing it in the `PropagationContext`. -1. If `sample_rand` is missing on an incoming trace, the SDK creates a new one applying **special rules** and uses it for the current execution context: + 1. Before using the incoming `sentry-sample_rand`, SDKs should validate that the value is a float in the range of `[0.0, 1.0)`. If the value is not a float, outside the valid range, or `NaN`, the SDK should ignore the incoming value. The SDK should instead generate a new `sample_rand` value for the current execution context, following the rules described below. The SDK should still propagate the invalid incoming `sentry-sample_rand` value to downstream SDKs. +1. If `sentry-sample_rand` is missing or invalid on an incoming trace, the SDK creates a new one applying **special rules** and uses it for the current execution context: 1. If `sample_rate` (inside `baggage`) and the sampling decision (trailing `-1` or `-0` from the `sentry-trace` header) are present in the incoming trace, create `sample_rand` so that when compared to the incoming `sample_rate` it would lead to the same sampling decision that is in the `sentry-trace` header. This means, for a decision of `True` generate a random number in half-open range `[0, rate)` and for a decision of `False` generate a random number in range `[rate, 1)`. 1. If the sampling decision is missing on the incoming trace, generate a random number in range of `[0, 1)` (including 0.0, excluding 1.0), like for a new trace.