From a1afaf8c028e9934c3bc6f6c1c54bfcf986b0ccc Mon Sep 17 00:00:00 2001 From: Katie Byers Date: Wed, 30 Nov 2022 11:25:02 -0800 Subject: [PATCH] make code review fixes --- .../product/accounts/quotas/manage-event-stream-guide.mdx | 2 +- src/docs/product/accounts/quotas/manage-transaction-quota.mdx | 2 +- src/platforms/common/configuration/options.mdx | 4 ++-- src/platforms/common/data-management/sensitive-data/index.mdx | 2 +- src/platforms/common/enriching-events/event-processors.mdx | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/docs/product/accounts/quotas/manage-event-stream-guide.mdx b/src/docs/product/accounts/quotas/manage-event-stream-guide.mdx index fc3110c4f5a8b..5ebe0269c740c 100644 --- a/src/docs/product/accounts/quotas/manage-event-stream-guide.mdx +++ b/src/docs/product/accounts/quotas/manage-event-stream-guide.mdx @@ -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} diff --git a/src/docs/product/accounts/quotas/manage-transaction-quota.mdx b/src/docs/product/accounts/quotas/manage-transaction-quota.mdx index 6d0a046697d56..57a03c288fe53 100644 --- a/src/docs/product/accounts/quotas/manage-transaction-quota.mdx +++ b/src/docs/product/accounts/quotas/manage-transaction-quota.mdx @@ -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} diff --git a/src/platforms/common/configuration/options.mdx b/src/platforms/common/configuration/options.mdx index 0e5b35219899d..6103da06f58e3 100644 --- a/src/platforms/common/configuration/options.mdx +++ b/src/platforms/common/configuration/options.mdx @@ -252,7 +252,7 @@ Most SDKs will attempt to auto-discover this value. -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. @@ -569,7 +569,7 @@ This function is called with an SDK-specific message or error event object, and -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. diff --git a/src/platforms/common/data-management/sensitive-data/index.mdx b/src/platforms/common/data-management/sensitive-data/index.mdx index 81fcda0ecb9cc..a198a29eb4857 100644 --- a/src/platforms/common/data-management/sensitive-data/index.mdx +++ b/src/platforms/common/data-management/sensitive-data/index.mdx @@ -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 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 hook which does the same thing for transactions.) Using and 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 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 hook which does the same thing for transactions. We recommend using and in the SDKs to **scrub any data before it is sent**, to ensure that sensitive data never leaves the local environment. diff --git a/src/platforms/common/enriching-events/event-processors.mdx b/src/platforms/common/enriching-events/event-processors.mdx index 42212376b9587..88c80b1ed3cc2 100644 --- a/src/platforms/common/enriching-events/event-processors.mdx +++ b/src/platforms/common/enriching-events/event-processors.mdx @@ -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 a `hint` object containing extra metadata.