Potential Trace propagation bug in browser SDK

[Lms24]

Description

Just discovered this trace in the Sentry UI:

There seems to be an orphaned http.server transaction which gets a sentry-trace header with a span id that doesn't exist:

Assuming the orphaned transaction was started after the navigation span finished. It's expected that there's no frontend transaction, given we don't start http.client spans as root spans. However, the parent span id of the orphaned transaction does not exist (=> orphan). Why did this happen? My guess is that we propagate an incorrect span id here. We should propagate the navigation span's id as the parent span id.

To do:

• reproduce if possible
• double check trace propagation logic when there's no active span

[Lms24]

Side note: There's something else super weird going on in this trace. TIme stamps from server and client are completely off. This raises questions:

• is the one problem related to the other
• who's wrong? server or client?
• Is this an SDK issue? If so, which SDK's issue?

[Lms24]

Turns out everything described here is expected behavior with the current browser tracing model.
The non-existing parent span exists because we have to propagate a span id in sentry-trace. Since there is no active span at the time, we propagate a random id.