After this change, EventScrubber is initialized from data_collection["user_info"], but should_send_default_pii() (line 753) still reads only options["send_default_pii"]. A user who migrates to data_collection={"user_info": True} without setting send_default_pii=True will find EventScrubber won't scrub PII fields, yet all integration code paths guarded by should_send_default_pii() — including scope user attachment (scope.py:1749), cookies, IP addresses, and dozens of integrations — will still suppress PII, leaving the configuration in a silently split state.

_Client.should_send_default_pii() still reads options["send_default_pii"] directly, so setting data_collection={"user_info": True} without send_default_pii=True causes EventScrubber (now driven by data_collection["user_info"]) to operate in PII-on mode while all integrations and scope.py that call should_send_default_pii() still return False, contradicting the user's explicit intent.

Using is not False identity checks for include_local_variables and include_source_context means an explicit None value is treated as True here, while resolve_data_collection passes None directly to _map_from_send_default_pii (where it's falsy). If a user passes either option as None, the spotlight override would produce a data_collection inconsistent with the initial resolution. Consider using the raw option values directly (matching resolve_data_collection's approach) or explicitly coercing with bool(...).

_resolve_explicit passes d.get("http_headers", {}) straight into _http_headers_from_value without verifying the value is a dict. Inside, the guard "request" in val performs a substring check when val is a string. If a user passes a string like "off" (which contains neither "request" nor "response"), the code silently falls back to the deny_list default — meaning a user attempting to disable header collection actually still collects headers (a PII concern). If instead the string contains "request" or "response" as a substring (e.g. "request_off"), val["request"] performs string indexing and raises a cryptic TypeError/AttributeError in _kvcb_from_value rather than a clear validation error. The test test_http_headers_collection_defaults exercises "off" and confirms the silent-fallback path, but no validation rejects malformed values.

Also found at:

• sentry_sdk/data_collection.py:152-158

With stacklevel=2, the warning points to _get_options() in client.py rather than the user's sentry_sdk.init() call, making it hard for users to locate the offending line in their own code. A stacklevel of ~5 is needed to reach user code via resolve_data_collection → _get_options → _Client.__init__ → _init → user code.

Also found at:

• sentry_sdk/client.py:28

When a user passes a non-dict value for cookies or query_params (e.g. data_collection={"cookies": "off"}), _resolve_explicit forwards it to _kvcb_from_value, which calls val.get("mode", "deny_list") unconditionally. Strings and other non-dicts have no .get(), so this raises a confusing AttributeError at sentry_sdk.init time instead of the clear ValueError the module raises for other invalid modes. This is inconsistent with _http_headers_from_value, which for a string value uses the in substring operator ("request" in val) and silently falls back to the deny-list default. So one bad-input shape crashes and another is silently ignored. Impact is limited to SDK misconfiguration surfaced at startup (no security/runtime data impact); the concern is a misleading error and inconsistent validation.

When a user provides data_collection={"http_bodies": ["bad_value"]}, the list is accepted and stored without checking each item against ALL_HTTP_BODY_TYPES, silently producing an invalid configuration that downstream consumers may mishandle.

Arbitrary strings in the http_bodies list are accepted without error; if an invalid body type is supplied the SDK will silently never match any request body, making collection appear configured while nothing is actually captured.

In sentry_sdk/data_collection.py, _kvcb_from_value calls val.get(...) with no isinstance guard, so passing data_collection={"cookies": "off"} instead of data_collection={"cookies": {"mode": "off"}} raises an unhelpful AttributeError: 'str' object has no attribute 'get' during sentry_sdk.init(). Add an isinstance(val, dict) check at the top of _kvcb_from_value and raise a clear TypeError/ValueError for non-dict inputs so misconfiguration produces an actionable error.

Also found at:

• sentry_sdk/data_collection.py:164-180

In sentry_sdk/data_collection.py, resolve_data_collection emits a DeprecationWarning for send_default_pii with warnings.warn(..., stacklevel=2). Because the warning is raised deep in the SDK call chain (sentry_sdk.init() -> Client.__init__ -> _get_options() -> resolve_data_collection() -> warnings.warn), stacklevel=2 resolves to _get_options() in client.py rather than the user's sentry_sdk.init() call site. This makes the deprecation warning reference an unhelpful internal frame. Increase stacklevel to match the actual call depth from user code.

Also found at:

• sentry_sdk/data_collection.py:247-251