get_data_collection() in scope.py accesses Scope.get_client().data_collection, but no data_collection property or attribute is defined on BaseClient, NonRecordingClient, or _Client; the resolved value lives at self.options["data_collection"]. There is no __getattr__ fallback, so any call to this helper will raise AttributeError. The helper is currently unused (the PR notes the option is not yet hooked up), so this is a latent bug that will surface on first use.

The warnings.warn(..., stacklevel=2) in _resolve_data_collection (data_collection.py:248) will attribute the warning to the direct caller of _resolve_data_collection — _get_options() in client.py:353 — rather than the user's sentry_sdk.init() call, making the DeprecationWarning non-actionable. The actual user call chain is deeper: init() -> Client()/_Client.init -> get_options()/_get_options -> _resolve_data_collection, so the stacklevel would need to account for the full chain to point to user code.

Also found at:

• sentry_sdk/client.py:352
• sentry_sdk/data_collection.py:250-253

The "request" in val check on line 188 performs a Python substring test when val is a string, not a dict-key lookup. The existing test passes "off" and works only by coincidence ("off" contains no "request" substring); a value like "request_headers" would satisfy the in check and then val["request"] would raise a confusing TypeError: string indices must be integers rather than a clear validation error — while the sibling _kvcb_from_value raises AttributeError for the same class of invalid input.

Also found at:

• tests/test_data_collection.py:32-36