This adds node & browser integration tests to demonstrate the current behavior of "trace propagation" based on the current scope.
It shows that the behavior is not really consistent and we should probably adjust it, but for now this PR does no changes.
Browser
In browser, the propagation context of the current scope is always picked up. This means that if you call startSpan multiple times in the root, both started spans will have the same trace ID, and possibly the same parentSpanId if there was an incoming trace.
Node
In node, the propagation context is ignored for the root context. So in the root, started spans will have different traces, and will also ignore parentSpanId (which is only theoretical, there will never really be a parentSpanId on the root scope in node, realistically).
Outside of the root (so e.g. within any route handler, or even any withScope call), the behavior is the same as in browser - any started spans will share the same trace ID/parent span ID.
What should we take away from this?
In node, I would align the behavior to ignore the trace ID when we have no incoming trace (so no parentSpanId), and always use the traceId & parentSpanId if there is a parentSpanId on the scope (even the root scope, to be consistent).
In browser, we cannot make this change because we rely on this behavior for the extended traces after pageload/navigation spans have ended.
This adds node & browser integration tests to demonstrate the current behavior of "trace propagation" based on the current scope.
It shows that the behavior is not really consistent and we should probably adjust it, but for now this PR does no changes.
Browser
In browser, the propagation context of the current scope is always picked up. This means that if you call
startSpanmultiple times in the root, both started spans will have the same trace ID, and possibly the sameparentSpanIdif there was an incoming trace.Node
In node, the propagation context is ignored for the root context. So in the root, started spans will have different traces, and will also ignore parentSpanId (which is only theoretical, there will never really be a parentSpanId on the root scope in node, realistically).
Outside of the root (so e.g. within any route handler, or even any
withScopecall), the behavior is the same as in browser - any started spans will share the same trace ID/parent span ID.What should we take away from this?
In node, I would align the behavior to ignore the trace ID when we have no incoming trace (so no parentSpanId), and always use the traceId & parentSpanId if there is a parentSpanId on the scope (even the root scope, to be consistent).
In browser, we cannot make this change because we rely on this behavior for the extended traces after pageload/navigation spans have ended.