https://code.djangoproject.com/ticket/34063
The short summary of that ticket is that there was a significant behavioral difference between django.test.Client and django.test.AsyncClient: with AsyncClient, any view or middleware which attempted to access request.POST without first accessing request.body would raise an exception with an obscure message about trying to read too much data from the request body. This was fixed last month: https://github.com/django/django/commit/c4eaa67e2b880db778c9fe6d9854fbdfcc16ecd2 However, it does not explicitly fall under any of the criteria for backporting to older releases (https://docs.djangoproject.com/en/dev/internals/release-process/#supported-versions) so at the moment, the fix will only be available from Django 4.2 onward, and no previous Django versions will receive a backported version of the fix (though the bug is present back to at least Django 3.2, and I suspect but haven't confirmed all the way back to the introduction of AsyncClient in Django 3.1). I'd like to argue for an exception to the normal backport policy, and for #34063 to be backported to Django 4.1, 4.0, and 3.2 LTS. My reasoning here is that async support is an incredibly important part of the Python web ecosystem right now, and there is no good alternative to django.test.AsyncClient for testing some kinds of async code -- although the normal django.test.Client can hit URLs served by async views, it does not always trigger async code paths inside Django when doing so. For example, I came across #34063 while trying to test a middleware that supports both sync and async usage; only AsyncClient reliably exercises the async code path of such a middleware, but that triggers the bug unless I add throwaway accesses of request.body. Especially for authors of reusable applications/libraries that try to support a broad range of Django versions, many of whom (like me!) are finally getting around to async support, this is an unpleasant situation, since it will require the request.body workaround to be left in place in all such code for at least another 16 months or so (which is when Django 3.2 LTS will finally drop out of upstream support). And that's presuming such authors even know to put in the workaround -- it took me quite a bit of debugging and following up on irrelevant search results before I finally found #34063, and that's as someone who has deep familiarity with Django -- someone less experienced at delving into Django's internals to figure out root causes and likely search terms would probably have had an even worse time of it. Finally, if it had been discovered prior to any of the releases in which AsyncClient has been present, this would have been a clear release blocker; it's quite a serious bug that seems to have gone unnoticed for so long largely by accident (and, ironically, by under-testing of the testing tools). So I think the right thing to do, to help with Django's transition into async support and to avoid imposing unnecessary burdens of debugging on application and library authors, is to backport the fix from #34063 to the full set of currently-supported Django releases: 4.1, 4.0, and 3.2 LTS. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAL13Cg-Pexnfd7ynnOWEoLkmfM5gYhcMfHgkYzOG7nH8sWA9sQ%40mail.gmail.com.
