test(browser): Add test for current DSC transaction name updating behavior

[Lms24]

This PR adds a browser integration test that describes the current behaviour of how we update the transaction field in the DSC which is propagated via the baggage header and added to envelopes as the trace header.

Specifically, this test shows a somewhat typical scenario for browser-side routing instrumentation where we initially have a low-quality URL txn name and only after a while update the name with a parameterized route. This test however also shows that we continue to update (i.e. not freeze) the DSC for subsequent transaction name updates. This is something we might want to change in the future, so that we only once set the transaction field when we have a high-quality txn name and freeze it afterwards, as discussed with @cleptric.

For more information on the test scenario, take a look at the comment block in the test

Will open another PR with a Node integration test soon.

[mydea]

can we add 11. to send a request after the span has ended, and make sure what is sent then? as we keep the trace alive after that (but not on the active span anymore, but the propagation context) this is also a scenario, right?

[Lms24]

yup, good point. Let me add that

[Lms24]

Hmm so it looks like at the moment, the DSC is also re-generated and no span information is added at all, meaning we not only loose transaction name but also sample_rate and sampled

[Lms24]

argh this is also problematic for the sentry-trace header. In the same scenario, we omit the sampling decision:

(first 3 requests are happening while the span is active, the last one afterwards. Same traceId but different sampled flags)

[mydea]

let's reflect this in this PR I'd say and then see if we can fix/improve this in a follow up...?

[Lms24]

@mydea I think the behavior in this test is caused by the constructed scenario of us starting the trace by creating a custom span as opposed to a pageload or navigation span. I will look into what exactly is causing the transaction info to be missing while the traceId remains the same in this scenario. However, I added tests for the usual pageload transaction scenario where after the transaction ends we make requests/send additional spans. They have consistent DSC data from the initial pageload transaction.

==> we should have consistent behaviour today as long as browserTracingIntegration is used with default options for pageload/navigation.

[codecov]

❌ 6 Tests Failed:

Tests completed	Failed	Passed	Skipped
631	6	625	33

View the top 3 failed tests by shortest run time

tracing/trace-lifetime/pageload-meta/test.ts create a new trace for a navigation after the <meta> tag pageload trace

Stack Traces | 0.18s run time

test.ts:18:11 create a new trace for a navigation after the <meta> tag pageload trace

tracing/trace-lifetime/pageload-meta/test.ts error during <meta> tag pageload has pageload traceId

Stack Traces | 0.238s run time

test.ts:136:11 error during <meta> tag pageload has pageload traceId

tracing/trace-lifetime/pageload-meta/test.ts outgoing XHR request during <meta> tag pageload has pageload traceId in headers

Stack Traces | 0.264s run time

test.ts:247:11 outgoing XHR request during <meta> tag pageload has pageload traceId in headers

To view individual test run time comparison to the main branch, go to the Test Analytics Dashboard