Conversation
Replace sendDefaultPii guidance with granular Data Collection options across Java and Android documentation. Document defaults, migration behavior, integration coverage, and onboarding configuration. Co-Authored-By: Claude <noreply@anthropic.com>
Document the default-enabled filePaths control across Java and Android configuration surfaces. Correct migration and File I/O guidance so it matches the cumulative SDK implementation. Prefer Logback's scoped includeUnencodedMessage option instead of retaining the broad legacy PII switch. Co-Authored-By: Claude <noreply@anthropic.com>
Remove databaseQueryData from the Java and Android documentation while no production integration consumes it. Document the option when an integration can provide concrete configuration behavior. Co-Authored-By: Claude <noreply@anthropic.com>
Preserve the existing sendDefaultPii descriptions while marking the option as legacy. Align the Data Collected pages with current defaults and filtering behavior. Co-Authored-By: Claude <noreply@anthropic.com>
Restore pre-existing formatting changed during the Data Collection update. Keep quote, wrapping, XML, and snippet changes out of the branch diff. Co-Authored-By: Claude <noreply@anthropic.com>
Add comments after userInfo examples in Java setup snippets. Make it clear that developers can configure other collection categories. Co-Authored-By: Claude <noreply@anthropic.com>
Set Data Collection availability to 8.57.0 and clarify that enabling it ignores the legacy sendDefaultPii option. Co-Authored-By: Claude <noreply@anthropic.com>
Explain how key-value collection behavior maps to code and external settings. Link header controls to option details and limit Spring Boot properties to its guide. Co-Authored-By: Claude <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
1 Skipped Deployment
|
| <meta-data | ||
| android:name="io.sentry.data-collection.user-info" | ||
| android:value="false" /> | ||
| <meta-data |
There was a problem hiding this comment.
does the incoming_request make sense here? Android should only have outgoing, correct?
| - `DENY_LIST`: Collect values except those matching the built-in sensitive list or additional configured terms. | ||
| - `ALLOW_LIST`: Include plaintext values only for keys that match configured terms and don't match the built-in sensitive list. Sensitive values are always replaced with `"[Filtered]"`. | ||
|
|
||
| Matching is partial and case-insensitive. The built-in list includes terms such as `auth`, `token`, `secret`, `password`, `key`, `session`, and `identity`. Filtered values are replaced with `"[Filtered]"`. Custom deny-list terms extend the built-in list rather than replacing it. |
There was a problem hiding this comment.
Should we list all built-in terms? or add a link to where a user can find them?
| } | ||
| ``` | ||
|
|
||
| ### Migrating From `sendDefaultPii` |
There was a problem hiding this comment.
Should we also document somewhere that not all headers contained in HttpUtils.SENSITIVE_HEADERS are matched when datacollection is used. e.g. X-FORWARDED-FOR header will not be scrubbed by datacollections default Http.SENSITIVE_DATA_KEYS
| | Field | Type | Default | Behavior | | ||
| | ------------------------ | ---------------------------- | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | `userInfo` | `boolean` | `true` | Allows integrations to populate user identity and IP address information. | | ||
| | `cookies`\* | `KeyValueCollectionBehavior` | `DENY_LIST` | Collects cookies and filters sensitive values. | |
There was a problem hiding this comment.
KeyValueCollectionBehavior API is not listed/explained. Should there be a separate section to explain the usage and meaning of off(), allowList(...), denyList(...), setMode(), and setTerms?
| Configuration options will be loaded from the manifest so that you don't need to have the static properties in your code. In the `init` method, you can provide a callback that will modify the configuration and also register new options. | ||
|
|
||
| ```kotlin | ||
| import io.sentry.DataCollection; |
There was a problem hiding this comment.
was there before this PR already, so a bit of a cleanup. We can get rid of the semicolons here
|
|
||
| ## Logs | ||
|
|
||
| Log messages, parameters, and breadcrumb content may contain application data. Data Collection doesn't filter this content. Use `beforeBreadcrumb` or `beforeSend` when you need application-specific filtering. |
There was a problem hiding this comment.
More specific mention of options.getLogs().setBeforeSend(...)?
| ## Personally Identifiable Information (PII) | ||
|
|
||
| Our newer SDKs do not purposefully send PII to stay on the safe side. This behavior is controlled by an option called [`send-default-pii`](../../configuration/options/#sendDefaultPii). | ||
| Use [`dataCollection`](../../configuration/options/#dataCollection) to control user information, cookies, HTTP headers and bodies, URL query parameters, GraphQL content, and database query data added automatically by integrations. Its built-in filters replace sensitive key-value data with `"[Filtered]"` before the event leaves the device. |
There was a problem hiding this comment.
Do we actually control database query data with our current DataCollection implementation? if not, then we should remove it here and we don't need to add it in the options table (as suggested by another comment)
There was a problem hiding this comment.
we don't yet, will update
| ## Personally Identifiable Information (PII) | ||
|
|
||
| The SDK purposefully does not send PII to stay on the safe side. This behavior is controlled by an option called [`send-default-pii`](../../configuration/options/#sendDefaultPii). | ||
| Use [`dataCollection`](../../configuration/options/#dataCollection) to control user information, cookies, HTTP headers and bodies, URL query parameters, GraphQL content, and database query data added automatically by integrations. Its built-in filters replace sensitive key-value data with `"[Filtered]"` before the event leaves your application. |
There was a problem hiding this comment.
Do we actually control database query data with our current DataCollection implementation? if not, then we should remove it here and we don't need to add it in the options table (as suggested by another comment)
There was a problem hiding this comment.
we don't yet, will update
| }); | ||
| ``` | ||
|
|
||
| You can also configure Data Collection through external properties: |
There was a problem hiding this comment.
Maybe mention that options.setEnableExternalConfiguration(true); must be set, for the properties to have any effect for plain java projects without integrations?
| ## Request Body | ||
|
|
||
| The request body of incoming HTTP requests can be sent to Sentry. Whether it's sent or not, depends on the type and size of request body as described below: | ||
| All request and response body directions are enabled by default, but integrations collect bodies only where supported. Some integrations collect body content, while others collect only body sizes. |
There was a problem hiding this comment.
is that enough detail or should we list which integration supports which?
| | `cookies`\* | `KeyValueCollectionBehavior` | `DENY_LIST` | Collects cookies and filters sensitive values. | | ||
| | `httpHeaders.request`\* | `KeyValueCollectionBehavior` | `DENY_LIST` | Collects request headers and filters sensitive values. | | ||
| | `httpHeaders.response`\* | `KeyValueCollectionBehavior` | `DENY_LIST` | Collects response headers and filters sensitive values. | | ||
| | `httpBodies` | `Set<HttpBodyType>` | all body types | Collects supported incoming and outgoing request and response bodies. An empty set disables body collection. | |
There was a problem hiding this comment.
should we mention the connection to maxRequestBodySize here? its mentioned on the data collected page
Use the client-side request and response directions supported by Android integrations in the manifest example. Co-Authored-By: Claude <noreply@anthropic.com>
Document the complete built-in key-name term list so customers know which cookie, header, and query parameter values are filtered by default. Co-Authored-By: Claude <noreply@anthropic.com>
Warn that Data Collection does not automatically cover every header omitted by legacy filtering and document the extended identifying-data deny terms. Co-Authored-By: Claude <noreply@anthropic.com>
Show the public factory method for each key-value collection mode so users can translate the documented behavior directly into Java or Kotlin code. Co-Authored-By: Claude <noreply@anthropic.com>
Remove Java-style semicolons from the Kotlin initialization example and restore Prettier formatting in the manual setup page. Co-Authored-By: Claude <noreply@anthropic.com>
Explain that general HTTP header controls do not expose cookie values and point readers to the separate cookie Data Collection setting. Co-Authored-By: Claude <noreply@anthropic.com>
Distinguish sensitive header handling from URL and query string collection when OpenTelemetry attributes are mapped to Sentry requests. Co-Authored-By: Claude <noreply@anthropic.com>
Update the Kotlin manual setup example to modify the Data Collection object loaded from manifest metadata instead of replacing it. Co-Authored-By: Claude <noreply@anthropic.com>
Update the Java manual setup example to modify the Data Collection object loaded from manifest metadata instead of replacing it. Co-Authored-By: Claude <noreply@anthropic.com>
Identify the callbacks used to filter breadcrumbs, events, and Sentry Logs when Data Collection does not control their content. Co-Authored-By: Claude <noreply@anthropic.com>
Identify the callbacks used to filter breadcrumbs, events, and Sentry Logs when Data Collection does not control their content. Co-Authored-By: Claude <noreply@anthropic.com>
Stop claiming that Data Collection controls database query data because no Android integration currently applies that option. Co-Authored-By: Claude <noreply@anthropic.com>
Stop claiming that Data Collection controls database query data because no Java integration currently applies that option. Co-Authored-By: Claude <noreply@anthropic.com>
Point Data Collection property users to the external configuration setup required for plain Java applications. Co-Authored-By: Claude <noreply@anthropic.com>
List the integrations that collect body content and distinguish content controls from body-size metadata. Co-Authored-By: Claude <noreply@anthropic.com>
Explain how Spring and Spring Boot apply both Data Collection body directions and maxRequestBodySize without implying that the limit affects other bodies. Co-Authored-By: Claude <noreply@anthropic.com>
Replace constructor-based Data Collection setup with forceDataCollection() and update migration guidance for the explicit opt-in API. Co-Authored-By: Claude <noreply@anthropic.com>
Mark Data Collection as available in 8.58.0 for Java and Android. Co-Authored-By: Claude <noreply@anthropic.com>
Document the Java and Android Data Collection controls planned for SDK 8.57.0.
This explains the new defaults, migration behavior from
sendDefaultPii, built-in filtering, and configuration through code, properties, environment variables, Spring Boot, and Android manifest metadata. It also documents support across HTTP, GraphQL, Apollo, OkHttp, Ktor, OpenFeign, and File I/O integrations.Update onboarding examples to opt into Data Collection with
userInfo=false, matching the privacy-conscious JavaScript setup without adding unnecessary body configuration. Update Logback setup to load SDK options fromsentry.propertiesand document the scopedincludeUnencodedMessagecontrol.The documentation was checked against the cumulative sentry-java implementation rather than the original plan.
databaseQueryDataremains undocumented until a production integration consumes it.Related implementation: getsentry/sentry-java#5759
Refs getsentry/sentry-java#5666