Skip to content

ref(sdks): Wordsmith beforeSendTransaction docs #5869

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

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -338,7 +338,7 @@ The SDK sample rate is not dynamic; changing it requires re-deployment. Also, ke

## 7. SDK Filtering: beforeSend {#1-sdk-filtering-beforesend}

All Sentry SDKs support the `beforeSend` callback method. Once implemented, the method is invoked when the SDK captures an error event, right before sending it to your Sentry account. It receives the event object as a parameter, so you can use that to modify the event's data or drop it completely (by returning `null`) based on your custom logic and the data available on the event, like _tags_, _environment_, _release version_, _error attributes_, and so on. Note that only error and message events pass through `beforeSend`. Tansaction events have a separate method, `beforeSendTransaction`, though it is not yet supported in all SDKs. Learn more about both methods in [Filtering Events](/platform-redirect/?next=/configuration/filtering/).
All Sentry SDKs support the `beforeSend` callback method. Once implemented, the method is invoked when the SDK captures an error event, right before sending it to your Sentry account. It receives the event object as a parameter, so you can use that to modify the event's data or drop it completely (by returning `null`) based on your custom logic and the data available on the event, like _tags_, _environment_, _release version_, _error attributes_, and so on. Note that only error and message events pass through `beforeSend`. Tansaction events have a separate method, `beforeSendTransaction`, though it's not yet supported in all SDKs. Learn more about both methods in [Filtering Events](/platform-redirect/?next=/configuration/filtering/).

## 8. SDK Configuration {#2-sdk-configuration}

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -140,7 +140,7 @@ If you discover a problematic release causing excessive noise, Sentry supports i

## 3. SDK Filtering: beforeSendTransaction {#1-sdk-filtering-beforesendtransaction}

Some Sentry SDKs support the `beforeSendTransaction` callback method. Once implemented, the method is invoked when the SDK captures a transaction event, right before sending it to your Sentry account. It receives the transaction event object as a parameter, so you can use that to modify the event's data or drop it completely (by returning `null`) based on your custom logic and the data available on the event, like _tags_, _environment_, _release version_, _transaction name_, and so on. Note that only transaction events pass through `beforeSendTransaction`. Error and message events have a separate method, `beforeSend`, which is supported in all SDKs. Learn more about both methods in [Filtering Events](/platform-redirect/?next=/configuration/filtering/).
Some Sentry SDKs support the `beforeSendTransaction` callback method. Once implemented, this method is invoked when the SDK captures a transaction event, right before sending it to your Sentry account. Because it receives the transaction event object as a parameter, you can use it to modify the event's data or drop the event completely (by returning `null`) based on your custom logic and the data available on the event, such as _tags_, _environment_, _release version_, _transaction name_, and so on. Note that only transaction events pass through `beforeSendTransaction`. Error and message events have a separate method, `beforeSend`, which is supported in all SDKs. Learn more about both methods in [Filtering Events](/platform-redirect/?next=/configuration/filtering/).

## 4. SDK Configuration: Tracing Options {#2-sdk-configuration-tracing-options}

Expand Down
4 changes: 2 additions & 2 deletions src/platforms/common/configuration/options.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -252,7 +252,7 @@ Most SDKs will attempt to auto-discover this value.

<PlatformSection supported={["dotnet"]}>

For ASP.NET and ASP.NET Core applications, the value will default to the server's name. For other application types, the value will default to the computer's name only when the `SendDefaultPii` is set to `true`, because the computer's name can be considered personally identifiable information (PII) in the case of a desktop or mobile application.
For ASP.NET and ASP.NET Core applications, the value will default to the server's name. For other application types, the value will default to the computer's name only when the `SendDefaultPii` is set to `true`, because the computer's name can be considered personally identifiable information (PII) in the case of a desktop or mobile application.

</PlatformSection>

Expand Down Expand Up @@ -569,7 +569,7 @@ This function is called with an SDK-specific message or error event object, and

<ConfigKey name="before-send-transaction" supported={["javascript", "node"]}>

This function is called with an SDK-specific transaction event object, and can return a modified transaction event object, or `null` to skip reporting the event. This can be used, for instance, for manual PII stripping before sending.
This function is called with an SDK-specific transaction event object, and can return a modified transaction event object, or `null` to skip reporting the event. One way this might be used is for manual PII stripping before sending.

<PlatformSection supported={["javascript", "node"]}>

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -49,7 +49,7 @@ If you _do not_ wish to use the default PII behavior, you can also choose to ide

## Scrubbing Data

SDKs provide a <PlatformIdentifier name="before-send" /> hook, which is invoked before an error or message event is sent and can be used to modify event data to remove sensitive information. (Some SDKs also provide a <PlatformIdentifier name="before-send-transaction" /> hook which does the same thing for transactions.) Using <PlatformIdentifier name="before-send" /> and <PlatformIdentifier name="before-send-transaction" /> in the SDKs to **scrub any data before it is sent** is the recommended scrubbing approach, so sensitive data never leaves the local environment.
SDKs provide a <PlatformIdentifier name="before-send" /> hook, which is invoked before an error or message event is sent and can be used to modify event data to remove sensitive information. Some SDKs also provide a <PlatformIdentifier name="before-send-transaction" /> hook which does the same thing for transactions. We recommend using <PlatformIdentifier name="before-send" /> and <PlatformIdentifier name="before-send-transaction" /> in the SDKs to **scrub any data before it is sent**, to ensure that sensitive data never leaves the local environment.

<PlatformContent includePath="configuration/before-send" />

Expand Down
2 changes: 1 addition & 1 deletion src/platforms/common/enriching-events/event-processors.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ notSupported:

You can enrich events with additional data by adding your own event processors, either on the scope level or globally. Though event processors are similar to `beforeSend` and `beforeSendTransaction`, there are two key differences:

- `beforeSend` and `beforeSendTransaction` are guaranteed to be run last, after all other event processors, which means they gets the final version of the event right before it's sent (hence the name). Event processors added with either of the methods below run in an undetermined order, which means changes to the event may still be made after the event processor runs.
- `beforeSend` and `beforeSendTransaction` are guaranteed to be run last, after all other event processors, which means they get the final version of the event right before it's sent (hence the name). Event processors added with either of the methods below run in an undetermined order, which means changes to the event may still be made after the event processor runs.
- While `beforeSend`, `beforeSendTransaction`, and processors added with `Sentry.addGlobalEventProcessor` run globally, regardless of scope, processors added with `scope.addEventProcessor` only run on events captured while that scope is active.

Like `beforeSend` and `beforeSendTransaction`, event processors are passed two arguments, the event itself and <PlatformLink to="/configuration/filtering/#using-hints">a `hint` object</PlatformLink> containing extra metadata.
Expand Down