innov
/
django1
1
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity

Fixed #33495 -- Improved debug logging message about adapting handlers for middlewares. 

It's the wrapped handler that's adapted to the wrapping middleware.
This commit is contained in:
Aaron Chong 2022-02-09 01:25:33 +08:00 committed by Mariusz Felisiak
parent d35ce682e3
commit 2d472ad05c
3 changed files with 11 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
django/core/handlers/base.py
View File

@ -125,11 +125,11 @@ class BaseHandler:
if is_async: if is_async:
if not method_is_async: if not method_is_async:
if debug: if debug:
logger.debug("Synchronous %s adapted.", name) logger.debug("Synchronous handler adapted for %s.", name)
return sync_to_async(method, thread_sensitive=True) return sync_to_async(method, thread_sensitive=True)
elif method_is_async: elif method_is_async:
if debug: if debug:
logger.debug("Asynchronous %s adapted.", name) logger.debug("Asynchronous handler adapted for %s.", name)
return async_to_sync(method) return async_to_sync(method)
return method return method

6
docs/topics/async.txt
View File

@ -52,9 +52,9 @@ If you want to use these, you will need to deploy Django using
Middleware can be built to support :ref:`both sync and async Middleware can be built to support :ref:`both sync and async
<async-middleware>` contexts. Some of Django's middleware is built like <async-middleware>` contexts. Some of Django's middleware is built like
this, but not all. To see what middleware Django has to adapt, you can turn this, but not all. To see what middleware Django has to adapt for, you can
on debug logging for the ``django.request`` logger and look for log turn on debug logging for the ``django.request`` logger and look for log
messages about *"Synchronous middleware ... adapted"*. messages about *"Asynchronous handler adapted for middleware ..."*.
In both ASGI and WSGI mode, you can still safely use asynchronous support to In both ASGI and WSGI mode, you can still safely use asynchronous support to
run code concurrently rather than serially. This is especially handy when run code concurrently rather than serially. This is especially handy when

13
tests/middleware_exceptions/tests.py
View File

@ -222,8 +222,8 @@ class MiddlewareNotUsedTests(SimpleTestCase):
self.assertEqual(response.status_code, 200) self.assertEqual(response.status_code, 200)
self.assertEqual( self.assertEqual(
cm.records[0].getMessage(), cm.records[0].getMessage(),
"Asynchronous middleware middleware_exceptions.tests.MyMiddleware " "Asynchronous handler adapted for middleware "
"adapted.", "middleware_exceptions.tests.MyMiddleware.",
) )
self.assertEqual( self.assertEqual(
cm.records[1].getMessage(), cm.records[1].getMessage(),
@ -265,9 +265,8 @@ class MiddlewareSyncAsyncTests(SimpleTestCase):
self.assertEqual(response.status_code, 402) self.assertEqual(response.status_code, 402)
self.assertEqual( self.assertEqual(
cm.records[0].getMessage(), cm.records[0].getMessage(),
"Synchronous middleware " "Synchronous handler adapted for middleware "
"middleware_exceptions.middleware.async_payment_middleware " "middleware_exceptions.middleware.async_payment_middleware.",
"adapted.",
) )
@override_settings( @override_settings(
@ -295,8 +294,8 @@ class MiddlewareSyncAsyncTests(SimpleTestCase):
self.assertEqual(response.status_code, 402) self.assertEqual(response.status_code, 402)
self.assertEqual( self.assertEqual(
cm.records[0].getMessage(), cm.records[0].getMessage(),
"Asynchronous middleware " "Asynchronous handler adapted for middleware "
"middleware_exceptions.middleware.PaymentMiddleware adapted.", "middleware_exceptions.middleware.PaymentMiddleware.",
) )
@override_settings( @override_settings(