Sentry spamming RequestAborted on async django 5

[dima-kov]

How do you use Sentry?

Sentry Saas (sentry.io)

Version

sentry-sdk==2.6.0 django==5.0.6

Steps to Reproduce

1. django app on completely async stack;
2. sentry configuration:

sentry_sdk.init(
    dsn=SENTRY_DSN,
    traces_sample_rate=1.0 if ENV == Envs.Prod.value else 0.1,
    profiles_sample_rate=1.0,
    environment=ENV.value,
    send_default_pii=True,
    integrations=[
        DjangoIntegration(
            transaction_style="url",
            middleware_spans=True,
            signals_spans=False,
            cache_spans=False,
        ),
        AsyncioIntegration(),
    ],
)

3. run app with uvicorn via asgi: python -m uvicorn myproject.asgi:application
4. openning any view, accessing any admin url - sends RequestAborted error to sentry UI:

RequestAborted: null
  File "django/core/handlers/asgi.py", line 245, in listen_for_disconnect
    raise RequestAborted()

---

As we look into django code: https://github.com/django/django/blob/bcd255cd5ca0a1e686d276cca71f45ec400d84a2/django/core/handlers/asgi.py#L195-L202, raising this exception is expected for every http request, and is handled by django https://github.com/django/django/blob/bcd255cd5ca0a1e686d276cca71f45ec400d84a2/django/core/handlers/asgi.py#L209-L211 so we do not need to send errors on that.

Do you plan to fix this issue?

Expected Result

no error sent to sentry

Actual Result

[sentrivana]

Hey @dima-kov, thanks for reporting. Yeah this should not be reported. While we're working on a fix, in the meantime you can filter the error out by defining a custom before_send, see https://docs.sentry.io/platforms/python/configuration/options/#before-send

[sentrivana]

Ok I see what the problem is now. The DjangoIntegration is working correctly, ignoring the error as it should. It's the AsyncioIntegration that intercepts and reports the error. So disabling the integration is another possible temp solution.

[sentrivana]

For the time being, the custom before_send is the way to go here. The asyncio integration wraps all tasks indiscriminately and will report any exceptions that happened in a task and were not handled. It doesn't have the context to see that the exception is then ignored higher up.

So even though technically speaking both integrations are working as expected, the out of the box experience is definitely improvement worthy. What we could do is have a predefined denylist of exceptions to ignore in the AsyncioIntegration.

[dima-kov]

Would be great to update docs to describe the problem and potential fix example (before send)

[getsantry[bot]]

Assigning to @getsentry/support for routing ⏲️