Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(tracing): Propagate environment and release values in baggage Http headers #5193

Merged
merged 5 commits into from Jun 7, 2022

Conversation

Lms24
Copy link
Member

@Lms24 Lms24 commented Jun 2, 2022

Following #5133, this PR adds the sentry-environment and sentry-release values to the baggage HTTP headers of outgoing requests. We add these values to baggage as late as possible with the rationale that other baggage values (to be added in the future) will not be available right away, e.g. when intercepting baggage from incoming requests.

As a result, the flow described below happens, when the first call to span.getBaggage is made (e.g. in callbacks of instrumented outgoing requests):

  1. In span.getBaggage, check if there is baggage present in the span (in which case it was intercepted from incoming headers/meta tags) and it is empty (or only includes 3rd party data) OR if there is no baggage yet
  2. In both of these cases, populate the baggage with Sentry data (and leave 3rd party content untouched). Else do nothing
  3. Add this baggage to outgoing headers (and merge with possible 3rd party header)

Furthermore, the PR adds and improves tests to check correct handling and propagation of baggage

This PR does not yet sync the Http header baggage information with the one that's sent in the trace envelope header. This will be addressed in a follow-up PR.

EDIT: As discussed with the team, this PR does not fully address all (im)mutability cases. Will open up a separate PR soon to fix this.

ref: https://getsentry.atlassian.net/browse/WEB-936

@github-actions
Copy link
Contributor

github-actions bot commented Jun 2, 2022

size-limit report 📦

Path Size
@sentry/browser - ES5 CDN Bundle (gzipped + minified) 19.43 KB (-3.53% 🔽)
@sentry/browser - ES5 CDN Bundle (minified) 60.2 KB (-6.83% 🔽)
@sentry/browser - ES6 CDN Bundle (gzipped + minified) 18.23 KB (-3.32% 🔽)
@sentry/browser - ES6 CDN Bundle (minified) 53.82 KB (-7.15% 🔽)
@sentry/browser - Webpack (gzipped + minified) 19.99 KB (-13.96% 🔽)
@sentry/browser - Webpack (minified) 65.19 KB (-20.22% 🔽)
@sentry/react - Webpack (gzipped + minified) 20.02 KB (-14.01% 🔽)
@sentry/nextjs Client - Webpack (gzipped + minified) 43.95 KB (-8.54% 🔽)
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified) 25.56 KB (-1.98% 🔽)
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified) 24.11 KB (-1.52% 🔽)

@Lms24 Lms24 marked this pull request as ready for review June 2, 2022 11:11
Copy link
Member

@lforst lforst left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor remarks. Good tests!!

@@ -302,7 +311,14 @@ export class Span implements SpanInterface {
* @inheritdoc
*/
public getBaggage(): Baggage | undefined {
return this.transaction && this.transaction.metadata.baggage;
const existingBaggage = this.transaction && this.transaction.metadata.baggage;

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// Add sentry baggage data to baggage, only when baggage is either empty or does not exist yet

Took me a while to get what's happening here. Wdyt about adding a comment like this to speed things up for future readers?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, a note would be good. I slightly rewrote this part (and the condition on when to modify baggage) in the follow-up PR (#5205). Added a note there (50e0d19) instead because adding it here would require it to be rewritten.

@@ -334,6 +350,24 @@ export class Span implements SpanInterface {
trace_id: this.traceId,
});
}

/**
*
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we forgot to add a comment here ^^

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, good catch, thanks! Same thing though as above, I made modifications in #5205 (2a95a39) and added the JSdoc there.

*/
private _getBaggageWithSentryValues(baggage: Baggage = createBaggage({})): Baggage {
// eslint-disable-next-line @typescript-eslint/no-unsafe-member-access, @typescript-eslint/no-explicit-any
const hub: Hub = ((this.transaction as any) && (this.transaction as any)._hub) || getCurrentHub();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me this seems a bit dangerous. I was wondering if we can get away with only having getCurrentHub() here, because in a node context, we'll get the right hub anyways because of domains, and in a browser context we only have one proper hub anyways (?).

I'll let you make the final call on this though. It's probably a bit dangerous but should also be fine.

Copy link
Member Author

@Lms24 Lms24 Jun 3, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should be fine if we take the Hub from the transaction. When creating a Transaction, users can pass in a hub as an option in the TransactionContext. Also for example when calling hub.startTransaction. People who use a multi-hub/client setup (which comes with its own set of issues) do this sometimes.

Do you think it's dangerous because there might be a "wrong" hub in the transaction or because of the casts?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because of the casts.

},
});
});

test('Should assign `baggage` header which contains sentry trace baggage data of an outgoing request.', async () => {
test('Should assign `baggage` header which contains sentry trace baggage data to an outgoing request.', async () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we say in this test title explaining, that we don't overwrite baggage that's already on the outgoing request?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, thanks for bringing this up. Changed this title and the one below it
(this makes me think that I should add more tests covering different mutability cases here in #5205)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


describe('getBaggage and _getBaggageWithSentryValues', () => {
beforeEach(() => {
hub.getClient()!.getOptions = () => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think it's necessary to add a cleanup for this? Wanna avoid flakeyness in the future.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking the same thing when I wrote the tests here but then I saw that at the top of this file there already is a beforeEach function. This means that the modifications on the hub from my beforeSend, are reverted as soon as we leave the closure and move to other tests.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it. Seems good.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants