-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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(core): Add beforeSendTransaction
#6121
Conversation
size-limit report 📦
|
92d565a
to
ad5a70e
Compare
packages/core/test/lib/base.test.ts
Outdated
@@ -887,7 +887,7 @@ describe('BaseClient', () => { | |||
expect(capturedEvent).toEqual(normalizedTransaction); | |||
}); | |||
|
|||
test('calls beforeSend and uses original event without any changes', () => { | |||
test('calls `beforeSend` and uses original event without any changes', () => { |
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.
l: While re-writing these tests, an idea would also be to maybe nest them into describe('beforeSend')
and describe('beforeSendTransaction')
?
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.
I def think this test file could be streamlined/better organized more than I have here (some describe.each()
or it.each()
calls are probably in order), but for the sake of keeping it still relatively clear what changes are actually for beforeSendTransaction
and which are for re-org purposes, IMHO that should happen in a separate PR. (I may actually pull the re-org changes here out into a separate PR as it is. UPDATE: I did: #6135.)
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.
makes sense to me! 👍
ad5a70e
to
c3af67c
Compare
c3af67c
to
06c4664
Compare
This is a collection of a bunch of small and mostly dumb fixes pulled from #6121 (along with a few others I happened upon in the course of working on it), in order to make that PR easier to review. Some of the changes are cosmetic (formatting and wordsmithing test names, adding comments, etc.), some are refactors for clarity (mostly renaming of variables), one or two are test changes which will be necessary for the tests introduced in the aforementioned PR (in order to keep the `beforeSend` and `beforeSendTransaction` tests as parallel as possible, in case we ever want to parameterize them), one is pulling unneeded extra data out of a test to make it simpler, and two are actual fixes, namely: - In the outcomes test, we were recording a session being dropped by `beforeSend`, but sessions don't go through `beforeSend`, so it's now an error event. - In many places in the base client tests, we were using `.toBe()` rather than `toEqual()` for values (like numbers and strings) which as far as I know aren't guaranteed to be singletons (the way `true` and `false` are, for example). This switches to using `toEqual()` in those cases.
06c4664
to
5820734
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.
LGTM, just some remarks for the tests and JSDoc
(Hope it's okay that I reviewed the PR while it was in Draft. I figured from the description you let it in Draft while you were working on docs. If you still wanted to make changes feel free to dismiss this review)
|
||
client.captureEvent({ transaction: '/dogs/are/great', type: 'transaction' }); | ||
|
||
expect(TestClient.instance!.event!.transaction).toBe('/dogs/are/great'); |
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.
m: I think we should add a expect(beforeSendTransaction).toHaveBeenCalled()
assertion here to make sure that the function was actually called. The check we have in place here doesn't ensure this fully.
l to super-l: same in the other tests below but admittedly it's less of an issue there, so feel free to ignore there
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.
Valid point, but if I do it for beforeSendTransaction
, I should do it for beforeSend
as well. Not opposed to doing so, but I'll do it in a separate PR just to keep things simple.
UPDATE: Done in #6150.
5820734
to
84541f7
Compare
Hello, should there be an entry in the docs for this feature as well? https://develop.sentry.dev/sdk/features/#before-send-hook |
Hi @OrkhanAlikhanov, yes, we're working on that. For now, you should be able to follow the |
…`beforeSendTransaction` tests (#6150) Per @Lms24's suggestion[1], this adds a check to make sure the relevant function is being called in our `beforeSend` and `beforeSendTransaction` tests. [1] #6121 (comment)
Hi, can you please be more careful with introducing breaking changes like these: I could not find this change in the documentation, or the changelog. An API change would also warrant a major release, or at least an obsolete message somewhere. Thanks |
Hey @ehtb, could you clarify how this was a breaking change? We did not change any public APIs/behavior for existing event processors - only added new functionality here. |
Hi @AbhiPrasad AFAICT previously the transaction events were send through |
Thanks for checking @lobsterkatie. |
Hey @ehtb, awesome to hear you just integrated with the OpenTelemetry package. I helped build it, do you have some time to sit down and walk through your experiences with the package and your OpenTelemetry set up? We can also try debugging your transaction/ |
This adds a new
beforeSendTransaction
option to the SDK. As one would expect from the name, it works just likebeforeSend
(in other words, it's a guaranteed-to-be-last event processor), except that it acts upon transaction events, which the originalbeforeSend
doesn't.Docs PR to come.
Ref: getsentry/rfcs#19 (comment)