As discussed in our planning meeting on June 20, we will not continue to propagate incoming 3rd party baggage in the outgoing requests we instrument. Instead, we will:
On incoming requests:
- Only store
sentry- values from the baggage header (if there is one) on the transaction
On outgoing requests:
- Append our
sentry- values to an already existing baggage header
- Or add a
baggage header to outgoing requests if there is no header yet
The reason for this change is that it is not our responsibility to do the job of another vendor. In fact, if we continue to propagate 3rd party baggage, we might even propagate something that our users do not want to be propagated (e.g. which is why they would e.g. not install that verndor's SDK in the service where a Sentry SDK is).
We will of course continue to propagate baggage that was already added by another SDK before us in the outgoing request (and, as outlined above, just append our values to that header). In return, we can only expect the other vendors' SDKs to follow the W3C spec and do the same.
This is a good opportunity to review our Baggage API and potentially cut down a few bytes of bundle size for logic and functions that are not needed anymore after this change. One mandatory cleanup task:
As discussed in our planning meeting on June 20, we will not continue to propagate incoming 3rd party baggage in the outgoing requests we instrument. Instead, we will:
On incoming requests:
sentry-values from thebaggageheader (if there is one) on the transactionOn outgoing requests:
sentry-values to an already existingbaggageheaderbaggageheader to outgoing requests if there is no header yetThe reason for this change is that it is not our responsibility to do the job of another vendor. In fact, if we continue to propagate 3rd party baggage, we might even propagate something that our users do not want to be propagated (e.g. which is why they would e.g. not install that verndor's SDK in the service where a Sentry SDK is).
We will of course continue to propagate baggage that was already added by another SDK before us in the outgoing request (and, as outlined above, just append our values to that header). In return, we can only expect the other vendors' SDKs to follow the W3C spec and do the same.
This is a good opportunity to review our Baggage API and potentially cut down a few bytes of bundle size for logic and functions that are not needed anymore after this change. One mandatory cleanup task:
getBaggage()method from span to transaction (see ref(tracing): MovegetBaggage()fromSpantoTransactionclass #5299)