The docstring of _map_from_send_default_pii states that graphql.variables and database.query_params follow send_default_pii while graphql.document should stay True (the document itself is not treated as PII). The implementation instead sets "graphql": {"document": send_default_pii, "variables": send_default_pii}, so with the default send_default_pii=False, graphql.document resolves to False and GraphQL documents are silently suppressed. Consider {"document": True, "variables": send_default_pii} to match the documented behavior.

Also found at:

• sentry_sdk/data_collection.py:110
• tests/test_data_collection.py:131-140

The EventScrubber at line 357 now correctly uses data_collection["user_info"], but _Client.should_send_default_pii() (line 747) still reads directly from options["send_default_pii"]. Any user who sets data_collection={"user_info": True} without also setting send_default_pii=True will get a scrubber that allows PII through, while every integration calling should_send_default_pii() (fastapi, sanic, asgi, strawberry, rq, huey, etc.) will still return False and suppress PII collection — making the new option effectively broken for those integrations.

Also found at:

• sentry_sdk/client.py:752-753

BaseClient.data_collection (client.py:441) returns the module-level _DISABLED_DATA_COLLECTION_CONFIG dict directly, without copying. This dict contains nested mutable objects (a list for http_bodies, dicts for cookies/http_headers/query_params/etc.). It is exposed publicly via get_data_collection() / Scope.get_client().data_collection. If any future consumer mutates a nested field (e.g. client.data_collection["http_bodies"].append(...)), it would silently corrupt the shared constant for all callers of the non-recording/pre-init client path. No current caller mutates the returned structure, so this is a defensive hardening concern rather than an active bug. Consider returning a shallow/deep copy or an immutable structure.

The DeprecationWarning warning that send_default_pii is deprecated/ignored when data_collection is set uses stacklevel=2 in resolve_data_collection() (sentry_sdk/data_collection.py). Because the warning is emitted directly inside resolve_data_collection, stacklevel=2 attributes the warning to its immediate caller _get_options() in client.py, rather than the user's sentry_sdk.init() call, making the warning harder to act on.

In _resolve_explicit (sentry_sdk/data_collection.py), a user-supplied http_bodies value is passed directly to list(...) without checking it is a list. A string such as "incoming_request" is iterated character-by-character, producing ['i','n','c',...] instead of raising an error. Unlike key-value modes (validated via _kvcb_from_value against a whitelist), body type strings are never validated against ALL_HTTP_BODY_TYPES, so these bogus single-character entries pass through silently, effectively misconfiguring body collection without any diagnostic to the user.

Also found at:

• sentry_sdk/data_collection.py:167-168
• sentry_sdk/data_collection.py:185-194

In resolve_data_collection, the warnings.warn(..., stacklevel=2) for the send_default_pii/data_collection conflict uses stacklevel=2, which attributes the warning to the immediate caller of resolve_data_collection. That caller is _get_options() in client.py (the rv["data_collection"] = resolve_data_collection(rv) line), i.e. internal SDK code, not the user's sentry_sdk.init() call site. As a result the DeprecationWarning is unhelpfully attributed to SDK internals, making it harder for users to locate the offending configuration in their own code.

Also found at:

• sentry_sdk/data_collection.py:249-254

The property returns _DISABLED_DATA_COLLECTION_CONFIG directly by reference; any caller that mutates it (e.g., client.data_collection["http_bodies"].pop()) would corrupt the module-level singleton for all subsequent callers. Return a shallow copy or freeze the structure to prevent accidental mutation.

Also found at:

• sentry_sdk/client.py:391-397

In DSN-less spotlight mode, _Client._setup_once re-derives data_collection with include_local_variables=self.options["include_local_variables"] is not False (and the same for include_source_context). When the option is explicitly set to None (permitted by the Optional[bool] typing in consts.py:1312-1313), None is not False evaluates to True, so the re-derived dict stores stack_frame_variables=True/frame_context_lines=5. The normal path resolve_data_collection instead passes the stored None straight through (options.get("include_local_variables", True) returns None), yielding stack_frame_variables=None (falsy). This is opposite to how None is treated everywhere else (utils.py:615 uses a truthy if include_local_variables: check, i.e. None disables capture). Impact is limited: the resolved stack_frame_variables/frame_context_lines values are not yet consumed for actual stacktrace capture (client.py:850 and utils.py read include_local_variables directly), so this is currently an internal-consistency defect in the resolved data_collection dict rather than a behavior change.

The data_collection property returns self.options["data_collection"] with no fallback. The "data_collection" key is only injected by resolve_data_collection() inside _get_options(), which runs exclusively during __init__. When a _Client is unpickled, __setstate__ restores self.options = state["options"] and calls _init_impl() — which never calls _get_options(). Normal same-version pickle round-trips are safe because __getstate__ serializes self.options after it already contains the key. However, unpickling state produced by an older SDK version (serialized before this key existed) leaves self.options without "data_collection", causing a KeyError here (and also at line 637 in _init_impl under DSN-less spotlight mode). Prefer self.options.get("data_collection", _DISABLED_DATA_COLLECTION_CONFIG) to match the defensive pattern used by the adjacent should_send_default_pii() (self.options.get("send_default_pii") or False) and NonRecordingClient.data_collection.

The docstring (line 93) states that graphql.document stays True regardless of send_default_pii, but the implementation (line 110) sets graphql.document to the value of send_default_pii, so it becomes False when PII collection is off. The docstring misdescribes the actual PII-gating behavior.

Also found at:

• tests/test_data_collection.py:196-204