feat(core): Data Collection

[adinauer]

PR Stack (Data Collection)

• feat(core): Data Collection #5759
• feat(core): [Data Collection 1] Add configuration types #5760
• feat(core): [Data Collection 2] Expose SentryOptions API #5761
• feat(core): [Data Collection 3] Add policy resolver #5799
• feat(graphql): [Data Collection 4] Apply GraphQL policies #5800
• feat(database): [Data Collection 5] Apply query policy #5801
• feat(spring): [Data Collection 6] Apply incoming request body policy #5802
• feat(apollo): [Data Collection 7] Apply incoming response body policy #5803
• feat(apollo): [Data Collection 8] Apply outgoing request body policy #5804
• feat(graphql): [Data Collection 9] Apply outgoing response body policy #5805
• feat(http): [Data Collection 10] Apply request header policy #5806
• feat(http): [Data Collection 11] Apply response header policy #5807
• feat(http): [Data Collection 12] Apply query parameter policy #5810
• feat(http): [Data Collection 13] Apply cookie collection policy #5811
• feat(user): [Data Collection 14] Apply user information policy #5812
• fix(android): [Data Collection 15] Scope device info cache to SDK options #5831
• test(replay): [Data Collection 16] Keep Replay independent #5832
• fix(android): [Data Collection 17] Apply user info policy to distinct ID #5833
• fix(spring): [Data Collection 18] Bind key-value policies #5834
• fix(android): [Data Collection 19] Preserve installation ID #5937
• fix(ktor): [Data Collection 20] Exclude query parameters from span descriptions #5983
• fix(opentelemetry): [Data Collection 21] Exclude queries from span descriptions #5985

---

📜 Description

Collection PR for the Data Collection stack. The individual PRs add the configuration model, resolution and compatibility bridge, external configuration, filtering, and integration enforcement.

Squash-merge this PR into main only after every stack PR has been merged into this branch using merge commits.

💡 Motivation and Context

Introduce the specification-defined dataCollection configuration while preserving existing sendDefaultPii behavior for users who do not opt into the new namespace.

Refs #5666

💚 How did you test it?

This collection branch contains only an empty commit. Each stack PR carries its own tests.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

Merge the Data Collection stack into this branch in order, then squash-merge this PR into main.

#skip-changelog

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against dd4bdfc

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.48.0 (1)	release

⚙️ sentry-android Build Distribution Settings

[sentry-junior]

Reviewed the full Data Collection stack tip (fix/data-collection-opentelemetry-span-description) against data-collection 0.11.0 and the landed/in-flight peers (JS, Python, Cocoa, Ruby, Go).

What looks solid

• Config surface matches the required core: userInfo, cookies / httpHeaders / urlQueryParams key-value modes, directional httpBodies, graphQL, databaseQueryData.
• Explicit-namespace resolution matches peers: once any dataCollection field is set (or an empty DataCollection is assigned), omitted fields take spec defaults, not sendDefaultPii. That matches JS resolveDataCollectionOptions and Go/Ruby “opt into defaults”.
• Built-in sensitive terms match the denylist; partial case-insensitive matching and [Filtered] substitution look correct in HttpUtils.
• Integration wiring for Spring/Servlet/OkHttp/Ktor/Apollo/GraphQL is real and tested; Replay kept independent (spec 0.10.0); Android installation ID restored as non-userInfo identity (pragmatic, well motivated).
• Span descriptions stripping queries (Ktor/OTel) matches the structuring-data rule.

Please fix before merge

1. Legacy path still ships sensitive query values (and dual-path bypasses the denylist)

Spec: sensitive key-value data MUST be replaced with [Filtered] under automatic collection. Peers always run collection through a resolved policy (JS bridges sendDefaultPii → urlQueryParams: true / deny-with-PII-snippets, then filters; Go/Python/Cocoa same idea).

Java does not:

// UrlUtils.filterQueryParams
return resolver.isDataCollectionConfigured()
    ? HttpUtils.filterQueryParams(query, resolver.getUrlQueryParams())
    : query; // raw, including token=secret

This is covered as intentional in UrlUtilsTest (preserve legacy query values), and HTTP integrations fork the same way (isDataCollectionConfigured → new filter, else sendDefaultPii / old header drop). With default options (dataCollection absent, sendDefaultPii=false), request/span/breadcrumb query strings still attach token=secret whenever a query is collected.

Same dual-path issue on cookies: e.g. OkHttp legacy sendDefaultPii=true returns the raw cookie string with no sensitive denylist pass (Spring at least runs filterOutSecurityCookies*).

Fix shape: always resolve an effective KeyValueCollectionBehavior (spec default deny-list, or a legacy bridge like JS defaultPiiToCollectionOptions) and run all query/cookie/header collection through HttpUtils.filter*. Keep category on/off and PII-term bridges in the resolver; do not bypass scrubbing when the namespace is unset.

2. Public databaseQueryData is a no-op

DataCollection / DataCollectionResolver.isDatabaseQueryData() are public and tested, but tip-of-stack has zero JDBC/SQLite (or other) call sites. #5801’s enforcement was dropped (Preserve query descriptions), so users can set the option with no effect.

Spec note: databaseQueryData gates bound params / payloads / results, not necessarily sanitized db.query.text. If Java cannot separate literals safely, either:

• drop the public option until there is a real consumer, or
• document + enforce a concrete policy in sentry-jdbc / sentry-android-sqlite (and only suppress what the option is defined to control).

3. Non-Spring config surfaces still only know send-default-pii

Spring Boot binding works via SentryProperties extends SentryOptions + mutable KeyValueCollectionBehavior (#5834). ExternalOptions / sentry.properties and Android ManifestMetadataReader still only map send-default-pii. Peers expose dataCollection on their primary config path. At least property-file (and ideally manifest) keys for the new namespace should land with the stack, or the gap should be explicit in the PR/docs so hybrid and non-Spring users are not stuck on the legacy flag.

Spec / peer deltas (non-blocking, track explicitly)

Area	Java stack	Spec / peers
genAI, queues, stackFrameVariables, frameContextLines	omitted	required where platform collects that data; OK to defer if unused
graphql naming	getGraphql()	spec graphQL; Ruby/Python also snake/lower — fine if documented
Boolean shorthand for key-value (true/false)	modes + factories only	JS/Ruby accept bool shorthand — nice-to-have
Docs / wizard opt-out snippet	not in stack	spec MUST for init snippets
Major-version default flip	stay on sendDefaultPii until explicit dataCollection	same staged approach as JS pre-v11 / Cocoa v10

Bottom line

Architecture and explicit-namespace behavior are in good shape and aligned with other SDKs. I would not merge until (1) sensitive scrubbing cannot be skipped on the legacy path, and (2) databaseQueryData is either enforced or removed from the public API. (3) is strongly preferred in the same release train as the feature.

Happy to re-review after those land on the tip branch.