Request for documentation

[jeengbe]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/browser

SDK Version

n/a

Framework Version

n/a

Link to Sentry event

n/a

SDK Setup

No response

Steps to Reproduce

In https://github.com/getsentry/sentry-javascript/releases/tag/7.58.0, the changelog reads:

This means even if there is no sampled transaction/span, the SDK will still propagate traces to downstream services.

What does this mean? It essentially sounds like "even without tracing, you still get tracing", does it instead refer to linked errors from upstream to downstream?
The change is not clear to me 🙂

Expected Result

n/a

Actual Result

n/a

[AbhiPrasad]

Hey @jeengbe, thanks for writing in! See our docs: https://docs.sentry.io/platforms/node/usage/distributed-tracing/

let's say you had two Node services, A and B, where A sends a http request to B. In previous versions of the SDK, the only way tracing headers were attached to that http request was was if there was an active span/transaction during A's request handling.

Now this requirement no longer exists. Tracing headers are attached no matter if there is an active/transaction span (the header just indicates nothing was sampled).

Sentry uses traceIds to link all the "events" in it's system. This can be spans/transactions, errors, crons, or even replays.

[AbhiPrasad]

Also @jeengbe thanks for always asking questions and raising feedback, it's highly appreciated here! Feel like we need to get you some Sentry swag, if you shoot me an email at a + prasad + @ + sentry.io (remove the pluses), I can see we can get something organized :)

[jeengbe]

Hi, thanks for the answer!

What is not clear to me, however, is whether this changes anything for applications that do have tracing already enabled but for which the transaction chose not to be sampled.

If B had an error that caused a downstream failure in A, would Sentry now (with the change) also link those if the transaction wasn't sampled? From what I understand, that was not the case previously, and I hope this is what has changed now.

---

I haven't actually ever seen something like "This issue might be related to: <upstream event>" in practice, but that's how I assume that feature works.

[AbhiPrasad]

If B had an error that caused a downstream failure in A, would Sentry now (with the change) also link those if the transaction wasn't sampled? From what I understand, that was not the case previously, and I hope this is what has changed now.

Yup it should now link them, this was the principle intention behind this change.

I haven't actually ever seen something like "This issue might be related to: " in practice, but that's how I assume that feature works.

We do have the trace navigator on the issues, but some of product UI needs to be ironed out.

[jeengbe]

If B had an error that caused a downstream failure in A, would Sentry now (with the change) also link those if the transaction
wasn't sampled? From what I understand, that was not the case previously, and I hope this is what has changed now.

Yup it should now link them, this was the principle intention behind this change.

And it didn't link them before if the transaction was chosen not to be sampled? 😅 If so, then this is quite the upgrade

[AbhiPrasad]

And it didn't link them before if the transaction was chosen not to be sampled? 😅 If so, then this is quite the upgrade

yes it didn't link them.

The whole point is here is to try to divorce the idea of distributed tracing from performance monitoring. We're slowly introducing this to all of our SDKs getsentry/team-sdks#5