In _get_view_function_response's wrapped_view_function, the span-streaming setup block (the if has_span_streaming_enabled(...) branch, lines 81–110) runs outside capture_internal_exceptions(), which only wraps the configured_time and scope.add_event_processor calls (lines 71–78). Any SDK-internal exception raised while building header attributes (_filter_headers), accessing current_span._segment, or calling segment.set_attributes(attributes) will propagate out of the wrapped view function and crash the user's Chalice request. The else branch's scope.set_transaction_name(...) (line 130) is likewise unprotected; in the pre-change code the transaction-name setup was inside capture_internal_exceptions(). For example, if request_dict.get('headers', {}) returns None (key present with a None value), _filter_headers(headers, ...).items() raises AttributeError with no SDK guard to suppress it.

The new tests only cover the case where a pre-existing StreamedSpan segment is present, leaving the segment = None branch of the streaming path in chalice.py uncovered — including the separate client.flush() call that only fires in that branch. There is no test for span streaming enabled with no parent Lambda segment.

Also found at:

• sentry_sdk/integrations/chalice.py:14
• sentry_sdk/integrations/chalice.py:83-128

In the span-streaming branch of _get_view_function_response, the exception handler re-raises any ChaliceViewError before setting segment.status = SpanStatus.ERROR.value. ChaliceViewError is the base class for all explicit Chalice HTTP error responses, including 5xx variants like InternalServerError. When such an error is raised and an active segment exists (owned by the AWS Lambda integration), the segment is reported with status='ok' even though the request resulted in a server error. The accompanying test (test_span_streaming_existing_span_error) only exercises a plain Exception, which does take the status-setting path, so this branch is untested.