check_request_enabled.send() should not be called from an async context about django-cors-headers HOT 2 OPEN

There’s no edict that the synchronous send() function should not be called from an asynchronous context. It’s legitimate but it does prevent the receivers from being asynchronous.

I don’t think we can remove the call as that is backwards incompatible. Maybe we can add an asend() call, though that would require significant restructuring.

the signal is my least favourite feature. It was added before I took over maintenance and I haven’t removed it due to backwards compatibility concerns. In most cases I think subclassjng the middleware makes more sense, though it’s not documented or well structured. If you have a specific use case, perhaps we can find a way to support that through subclassing.

from django-cors-headers.

It’s legitimate but it does prevent the receivers from being asynchronous.

It also prevents the receivers from accessing the database (which is my use case; my code was broken after upgrading from an older version of django-cors-headers).

But I'm ok with subclassing. My only concern is that I had to copy&paste the whole add_response_headers method into my subclass just to make its async version and be able to use await in the middle of it.

from django-cors-headers.