When span streaming is enabled, cached request body form/JSON values are serialized verbatim and attached to the segment span as SPANDATA.HTTP_REQUEST_BODY_DATA. Unlike the normal event path—where the event processor / data scrubber replaces sensitive fields such as password with [Filtered]—the span attribute path applies no PII filtering. As a result, plaintext passwords and other sensitive form fields are sent to Sentry as span data. The code comment acknowledges sanitization is deferred to a future before_send_span hook that does not yet exist.

In _wrap_async_handler (sentry_sdk/integrations/starlette.py), extract_request_info() is invoked unconditionally before the handler runs. That method calls self.json() (→ request.json(), caching _json) and self.form() (→ request.body() + request.form(), caching _form), so the request body is still eagerly consumed on every JSON/form request. As a result, the PR's change to read cached _json/_form in _get_cached_request_body_attribute does not actually avoid eager consumption for streamed spans: by the time the finally block runs, the SDK itself has already populated _json/_form. The 'omit the attribute if the request body is not cached, since the endpoint may not have accessed it' rationale from the PR description is therefore defeated for JSON/form requests — the body is always cached by the SDK and thus always attached to the streamed span. This is a pre-existing/acknowledged consumption path rather than a new defect, but it means the stated goal of the change is not realized.