-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Add tracestate
header to outgoing requests
#3092
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
Add tracestate
header to outgoing requests
#3092
Conversation
HUMAN EDIT: Do not panic. These numbers are wrong for some reason. See #3092 (comment). size-limit report
|
9803596
to
a28a330
Compare
6255084
to
1d5691e
Compare
782a8ed
to
ee52cbd
Compare
tracestate
header to outgoing requeststracestate
header to outgoing requests
2339b90
to
4af65a8
Compare
1d5691e
to
b80f797
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice.
The only thing I don't like is tracestate
in Event.
Also it would be a bit easier if you kept code shuffles that do not affect (as far as I can figure out) the current PR into a separate PR ( I'm referring at compat.ts and misc.ts).
packages/core/src/request.ts
Outdated
return { | ||
body: JSON.stringify(event), | ||
type: event.type || 'event', | ||
url: api.getStoreEndpointWithUrlEncodedAuth(), | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: Not directly related to the PR but, Since we are now using envelopes for both transactions and sessions it would be good to have it also for events (so everything goes to the envelope endpoint).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I'm not sure why we don't. I have no opposition to doing so, but I presume error events were separated out for a reason. Perhaps @HazAT or @rhcarvalho would have more context here.
In any case, as you say - a question for another day.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving error events over to the new endpoint break compatibility for people running their own sentry server (with a version prior to the introduction of envelopes).
Future SDK versions might change this, likely on a new major version bump.
packages/core/src/request.ts
Outdated
const req: SentryRequest = { | ||
// The trailing newline is optional; leave it off to avoid sending unnecessary bytes. | ||
// body: `${envelopeHeaders}\n${itemHeaders}\n${JSON.stringify(event)\n}`, | ||
body: `${envelopeHeaders}\n${itemHeaders}\n${JSON.stringify(event)}`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: having a function (or an object) to build envelopes would be nicer (and a little bit more 'typed').
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, don't necessarily disagree. That code predated this PR, which just pulled it out into a separate method. What I take from the comments there, though, is that we're trying to keep the implementation as lightweight as possible, (presumably in aid of our never-ending quest to shrink our bundle size).
it("doesn't attach tracing headers to outgoing sentry requests", () => { | ||
nock('http://squirrelchasers.ingest.sentry.io') | ||
.get('/api/12312012/store/') | ||
.reply(200); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll probably need send tracing headers in the near future, especially if we continue to send events to the store endpoint (as opposed to the envelope endpoint).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will error events be subject to the same dynamic sampling, based on the same trace context, as transaction events?
92729aa
to
b240401
Compare
4af65a8
to
76b8b91
Compare
Both fixed. |
size-limit report
|
b240401
to
41e1467
Compare
76b8b91
to
3ee4735
Compare
41e1467
to
45ab20c
Compare
3ee4735
to
30c98f8
Compare
Going to merge this into the feature branch, just to be able to stick a pin somewhere. |
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.
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.
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.
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.
This adds the
tracestate
header to outgoing requests in both browser (XHR
andfetch
) and node (http
).Major components:
A new
tracestate
property on theTransaction
classtransactionContext
or computed when the transaction is createdtrace_id
,release
,environment
, andpublic_key
, with any=
padding on the end removedInclusion of a
tracestate
header on all outgoing requestsUse of the already-calculated value for
trace
envelope headerTests for all of the above
Reading and using incoming
tracestate
header values (including accounting for other vendors' data which might also be present, as well as multipletracestate
headers) will be handled in a later PR.