Skip to content

ref(tracing): Rework tracestate internals to allow for third-party data #3266

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

Conversation

lobsterkatie
Copy link
Member

There's no behavior change here - just a bunch of shifting things around so that

  1. tracestate data lives inside the new (since the previous PR's inception) metadata property on the Transaction class rather than directly on the transaction,

  2. the data is stored as an object rather than a string, so there will be somewhere to put other vendors' data,

  3. the value stored includes the sentry= (rather than just being the value) because that will match the may the third-party data is stored, and

  4. orphan spans can generate tracestate headers, too.

Comment on lines +46 to +48
this.metadata = transactionContext.metadata || {};
this.metadata.tracestate = this.metadata.tracestate || {};
this.metadata.tracestate.sentry = this.metadata.tracestate.sentry || this._getNewTracestate(this._hub);
Copy link
Member Author

Choose a reason for hiding this comment

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

Is there a nicer/more compact way to do this? This feels like a lot of code, but I don't know of a setter version of the ?. getter syntax.

Copy link
Contributor

@kamilogorek kamilogorek Feb 17, 2021

Choose a reason for hiding this comment

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

No, not really, but we do this in so many places, that I might actually write

getOrDefault(this, 'metadata.tracestate.sentry', this._getNewTracestate(this._hub))

helper for this :<

Copy link
Contributor

Choose a reason for hiding this comment

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

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, except we also need to set the data. I think a helper isn't a bad idea, but I'll save that for a separate PR.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 17, 2021

size-limit report

Path Size
@sentry/browser - CDN Bundle (gzipped) 26.88 KB (+0.06% 🔺)
@sentry/browser - Webpack 27.81 KB (+0.06% 🔺)
@sentry/react - Webpack 27.83 KB (+0.06% 🔺)
@sentry/browser + @sentry/tracing - CDN Bundle (gzipped) 34.18 KB (+0.13% 🔺)

Copy link
Contributor

@kamilogorek kamilogorek left a comment

Choose a reason for hiding this comment

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

Other than this one comment, 👍

try {
tracestate = JSON.parse(base64ToUnicode(encodedTracestate as string));
const encodedSentryValue = (tracestate?.sentry as string).replace('sentry=', '');
reinflatedTracestate = JSON.parse(base64ToUnicode(encodedSentryValue));
} catch (err) {
logger.warn(err);
Copy link
Contributor

Choose a reason for hiding this comment

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

This would log Cannot read property 'replace' of undefined for situations when there's simply no tracestate.sentry which might be confusing to the user.

Copy link
Member Author

@lobsterkatie lobsterkatie Feb 17, 2021

Choose a reason for hiding this comment

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

True. Originally I had it as const encodedSentryValue = tracestate!.sentry!.replace('sentry=', '');, since if we get to that point and there's no tracestate.sentry, things have gone real wrong, but then it was yelling at me about the !. But I think maybe I should change it back, to better communicate to the reader that it's not optional.

Or maybe I can write my types in a smarter way... In any case, will fix it one way or another.

UPDATE: Okay, tried with the types, but there are too many stages at which this or that property may (legitimately) not be defined, so I'm going with the !.

@lobsterkatie lobsterkatie merged commit 78251cc into kmclb-dynamic-sampling-data-in-envelopes Feb 17, 2021
@lobsterkatie lobsterkatie deleted the kmclb-pre-third-party-tracestate-refactor branch February 17, 2021 17:47
lobsterkatie added a commit that referenced this pull request Aug 24, 2021
This is the result of rebasing the feature branch for the initial implementation of `tracestate` header handling (which had grown very stale) on top of current `master`. That branch is going to get deleted, so for posterity, it included the following PRs (oldest -> newest):

feat(tracing): Add dynamic sampling correlation context data to envelope header (#3062)
chore(utils): Split browser/node compatibility utils into separate module (#3123)
ref(tracing): Prework for initial `tracestate` implementation (#3242)
feat(tracing): Add `tracestate` header to outgoing requests (#3092)
ref(tracing): Rework tracestate internals to allow for third-party data (#3266)
feat(tracing): Handle incoming tracestate data, allow for third-party data (#3275)
chore(tracing): Various small fixes to first `tracestate` implementation (#3291)
fix(tracing): Use `Request.headers.append` correctly (#3311)
feat(tracing): Add user data to tracestate header (#3343)
chore(various): Small fixes (#3368)
fix(build): Prevent Node's `Buffer` module from being included in browser bundles (#3372)
fix(tracing): Remove undefined tracestate data rather than setting it to `null` (#3373)

More detail in the PR description.
lobsterkatie added a commit that referenced this pull request Aug 30, 2021
This is the result of rebasing the feature branch for the initial implementation of `tracestate` header handling (which had grown very stale) on top of current `master`. That branch is going to get deleted, so for posterity, it included the following PRs (oldest -> newest):

feat(tracing): Add dynamic sampling correlation context data to envelope header (#3062)
chore(utils): Split browser/node compatibility utils into separate module (#3123)
ref(tracing): Prework for initial `tracestate` implementation (#3242)
feat(tracing): Add `tracestate` header to outgoing requests (#3092)
ref(tracing): Rework tracestate internals to allow for third-party data (#3266)
feat(tracing): Handle incoming tracestate data, allow for third-party data (#3275)
chore(tracing): Various small fixes to first `tracestate` implementation (#3291)
fix(tracing): Use `Request.headers.append` correctly (#3311)
feat(tracing): Add user data to tracestate header (#3343)
chore(various): Small fixes (#3368)
fix(build): Prevent Node's `Buffer` module from being included in browser bundles (#3372)
fix(tracing): Remove undefined tracestate data rather than setting it to `null` (#3373)

More detail in the PR description.
lobsterkatie added a commit that referenced this pull request Aug 31, 2021
This is the result of rebasing the feature branch for the initial implementation of `tracestate` header handling (which had grown very stale) on top of current `master`. That branch is going to get deleted, so for posterity, it included the following PRs (oldest -> newest):

feat(tracing): Add dynamic sampling correlation context data to envelope header (#3062)
chore(utils): Split browser/node compatibility utils into separate module (#3123)
ref(tracing): Prework for initial `tracestate` implementation (#3242)
feat(tracing): Add `tracestate` header to outgoing requests (#3092)
ref(tracing): Rework tracestate internals to allow for third-party data (#3266)
feat(tracing): Handle incoming tracestate data, allow for third-party data (#3275)
chore(tracing): Various small fixes to first `tracestate` implementation (#3291)
fix(tracing): Use `Request.headers.append` correctly (#3311)
feat(tracing): Add user data to tracestate header (#3343)
chore(various): Small fixes (#3368)
fix(build): Prevent Node's `Buffer` module from being included in browser bundles (#3372)
fix(tracing): Remove undefined tracestate data rather than setting it to `null` (#3373)

More detail in the PR description.
lobsterkatie added a commit that referenced this pull request Sep 15, 2021
This is the result of rebasing the feature branch for the initial implementation of `tracestate` header handling (which had grown very stale) on top of current `master`. That branch is going to get deleted, so for posterity, it included the following PRs (oldest -> newest):

feat(tracing): Add dynamic sampling correlation context data to envelope header (#3062)
chore(utils): Split browser/node compatibility utils into separate module (#3123)
ref(tracing): Prework for initial `tracestate` implementation (#3242)
feat(tracing): Add `tracestate` header to outgoing requests (#3092)
ref(tracing): Rework tracestate internals to allow for third-party data (#3266)
feat(tracing): Handle incoming tracestate data, allow for third-party data (#3275)
chore(tracing): Various small fixes to first `tracestate` implementation (#3291)
fix(tracing): Use `Request.headers.append` correctly (#3311)
feat(tracing): Add user data to tracestate header (#3343)
chore(various): Small fixes (#3368)
fix(build): Prevent Node's `Buffer` module from being included in browser bundles (#3372)
fix(tracing): Remove undefined tracestate data rather than setting it to `null` (#3373)

More detail in the PR description.
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.

2 participants