rfc(decision): Propagation Context Evolution

[lforst]

Proposal to make propagation context not required on scopes.

Rendered RFC

[mydea]

This makes sense to me - we just need to make sure there are no unexpected consequences of this, but IMHO this appears more correct to me than what we have been doing.
One area to think about there is replay, as a replay will then span multiple traces which it does not do right now! Cc @billyvg thoughts on implications of this? Would this make sense? Or should we only attach the "first" (pageload) trace to the replay?

[lforst]

This makes sense to me - we just need to make sure there are no unexpected consequences of this, but IMHO this appears more correct to me than what we have been doing. One area to think about there is replay, as a replay will then span multiple traces which it does not do right now! Cc @billyvg thoughts on implications of this? Would this make sense? Or should we only attach the "first" (pageload) trace to the replay?

A replay should imo not have a trace ID. That doesn't make sense because a replay can span multiple traces, e.g. a pageload trace and multiple navigation traces. However, all the things (errors, spans, profiles) that happen within a replay should have a replay ID. That replay ID is currently also propagated with baggage so that downstream services can also attach to a particular replay.

It's good to keep replay in mind for this, but it shouldn't be a blocker here I think! (at least conceptually)

[billyvg]

Yeah the replay itself shouldn't have a trace id, since it lives beyond multiple traces. Replay collects the trace ids of all events that occur while the replay is running. If we do erroneously attach a trace id to the replay, I don't believe that we use it in any way.

[lforst]

Closing. We will have a PR for this in the develop docs.