In BODY_FORM, str(base64.b64encode(open(PICTURE, "rb").read())) produces a string like "b'/9j/4AAQ...'" (with the literal b' prefix and trailing quote), which is not valid base64. The Content-Transfer-Encoding: base64 field therefore contains malformed data. The tests still pass only because the server treats the photo field as opaque file content and Sentry redacts it, so the assertion (event["request"]["data"]["photo"] == "") does not exercise the base64 content. Consider using .decode('ascii') instead.

The three new tests (test_request_info_json_body, test_formdata_request_body, test_request_body_too_big) initialize Sentry with only StarletteIntegration(), while every other test in this file uses StarletteIntegration() and FastApiIntegration() together, which reflects the real-world FastAPI setup. Request body capture itself is performed by the Starlette middleware layer, so the tests do validate the behavior, but the integration setup is inconsistent with the rest of the file. Have you considered adding FastApiIntegration() to these tests to exercise the full FastAPI stack and match the established pattern?

In the new FastAPI test, BODY_FORM substitutes {{image_data}} with str(base64.b64encode(open(PICTURE, "rb").read())). Wrapping the bytes returned by b64encode in str() yields the Python bytes repr (e.g. b'/9j/...', including the b' prefix and trailing quote) rather than a valid base64 string, so the multipart body sent to /body/form contains malformed base64 for the photo field. The Django ASGI equivalent (tests/integrations/django/asgi/test_asgi.py:664) correctly uses .decode("utf-8"). The test still passes because it only asserts the photo field is captured as "" (line 176), masking the defect. Use .decode("utf-8") instead of str().

Also found at:

• tests/integrations/fastapi/test_fastapi.py:166

The three new POST-body tests (test_request_info_json_body, test_formdata_request_body, test_request_body_too_big) pass only StarletteIntegration() to sentry_init, so FastApiIntegration is not activated. Since these were adapted from the Starlette suite into a test(fastapi) PR, they should register FastApiIntegration() alongside StarletteIntegration() (as most other tests in this file do) so the FastAPI-specific code path is exercised. This is a test-completeness/consistency gap, not a functional defect: request body capture is handled by Starlette's ASGI middleware, so the tests still pass.