Document event processors in the SDK where it is supported.

[rodolfoBee]

Core or SDK?

Platform/SDK

Which part? Which one?

SDKs

Description

Multiple SDKs offer event processors that are called before the event goes into the beforeSend callback, but it is not described in the docs how to add them to the SDK.

Because transaction events do not go through beforeSend, event processors are the only option a customer has to change data, such as scrubbing PII from transactions at the SDK level.

In addition, we mention hints can be used in event processor and beforeSend/beforeBreadcrumb, and just mentioning it without describing

Suggested Solution

The event processor can be added to the filtering page as an alternative option, or have a separate session for them. A sample page can be created for the web SDKs and expanded to the other pages as the code snippets are added.

For example, here is a code snipet for JavaScript:

Sentry.addGlobalEventProcessor((event, hint) => {
  // some logic
  return event
})

and Python:

from sentry_sdk.scope import add_global_event_processor

def myEventProcessor(event, hint):
    ## some logic
     return event

sentry_sdk.scope.add_global_event_processor(myEventProcessor)

[imatwawana]

@getsentry/team-web-sdk-frontend and @getsentry/team-web-sdk-backend what do you think?

[imatwawana]

@rbisol - Can you please make your GitHub profile public. This ensures that issues raised by Sentry employees don't get counted for our triage SLOs. Thanks!

[AbhiPrasad]

This applies for every SDK - so Mobile and Native teams as well. Do we have a catch-all in these cases?

[imatwawana]

This applies for every SDK - so Mobile and Native teams as well. Do we have a catch-all in these cases?

Since Rodolfo suggested starting with JS and Python, I wanted to start the discussion with these two teams.

[AbhiPrasad]

Sure, then I think we can assign to the backend sdk team to start, and move on from there.

[lobsterkatie]

My vague recollection is that leaving event processors undocumented was, at least at the time, intentional, because we weren't dead sure the API was going to stick around. But then we decided not to have transactions go through beforeSend and so event processors became folks' only option, ensuring their continued existence. IDK if there's more to think about on this score before finally putting the issue to bed or not, so I've added it to the agenda to discuss with the larger team this week.

[sl0thentr0py]

fwiw, bikeshed:
naming one hook beforeSomething and another processor is also just bad practice. It is fine if we don't want to let beforeSend take in transactions but then at least we should call the other thing beforeSomething too.

[lobsterkatie]

fwiw, bikeshed: naming one hook beforeSomething and another processor is also just bad practice. It is fine if we don't want to let beforeSend take in transactions but then at least we should call the other thing beforeSomething too.

While agree with you that we need a beforeSendTransaction or something, to be fair event processors and beforeSend are slightly different, in that there can be many of the former (which are used to do all kinds of things, including by our integrations) and only one of the latter (which has only one job, and is only ever defined by the user). So it makes sense to me that they're named differently. The problem isn't their naming, it's that they're the hack we're forced to turn to because transactions don't have a proper beforeSend.

[sl0thentr0py]

This came up at djangocon too fwiw, PII scrubbing on transactions (for request headers) literally does not work right now due to our random design limitation of order preference between global and scope event processors. The only way they can get the right order is to add another WSGI middleware and do configure_scope/scope.add_event_processor which is just an awful suggestion to give to a user who wants to solve this simple problem.

See getsentry/sentry-python#1226 (comment) for an example.

I'm just going to add beforeSendTransaction to python at this point if no one objects in a couple of weeks.

[lobsterkatie]

RFC for beforeSendTransaction is here: getsentry/rfcs#19

[rahulchhabria]

@stephanie-anderson i think we can close this ticket. could you do a quick check, please? thank you.