Just to clarify this point, which I think has been glossed over: > But unless I'm misunderstanding the nature of the bug, this seems like it basically makes async views un-testable ...
This isn't correct. Under normal circumstances you just use the sync Client, as you've always done. `response = client.get(`/my-async-view/`)`. Django handles that the **view** is async for you. It's only if you need to write an actual **async test**, i.e. an `async def` test case that you need the async client and factory. The factory can use the suggested `request.body` workaround if needed. Where you need async def tests, dropping down to the request factory is available. An example might be testing a middleware for async support in isolation, which fits the request factory model directly. The `AsyncClient` is affected, yes. The question is whether that justifies a backport at this very late hour. On Fri, 30 Dec 2022 at 23:59, Kevin Grinberg <ke...@activefrequency.com> wrote: > I'll say upfront that I haven't hit this particular issue, but it's mostly > because I've avoided the Django async stack after some challenging > experiences on the old(er) channels/daphne/etc. stack and its evolution. > I've personally been in the "let's see how this develops" camp, which > admittedly isn't the most community-focused. I'll resolve to do better in > the new year. > > This does sort of get at one aspect of this issue though - there's less > usage of the async stuff as it's being rolled out slowly across multiple > releases (which it itself an experiment of sorts), in part because [at > least] some people don't trust it to actually be stable and are waiting to > see the whole story before committing projects more fully. > > So from the perspective of "how many users are impacted", I agree the > impact is probably low. But unless I'm misunderstanding the nature of the > bug, this seems like it basically makes async views un-testable without a > pretty annoying workaround (assuming it's more than a handful of views)? > Plus the fact that it's not easily discoverable. > > FWIW (I'm an n of 1 obviously), but I go LTS-to-LTS for most projects, > just given uncertainty in when I'll be upgrading any particular project, > and wanting to be certain I never fall out of support for at least security > releases. So for my own personal needs, fair enough - by the time I migrate > my 3.2 projects to 4.2, this will be fixed, and it's unlikely that I'll > personally be experimenting with async views in the next 3 months or so. > But that doesn't really seem like the sort of behavior we want to > encourage, if we're trying to actually get people to use async, get some > real-world usage, and signal that Django has a good async story. > > I'm very cognizant of maintenance burden and feel sheepish advocating for > someone else to do work, but if this thread is asking for opinions, I do > think it's important to backport this issue. I can't literally equate it to > a data loss bug (the specific example in the policy), but I'd argue that > the gradual nature of the async rollout and its importance in moving Django > forward mitigates for an exception to the backport policy. > > Cheers, > Kevin > > > On Friday, December 30, 2022 at 5:24:51 PM UTC-5 timog...@gmail.com wrote: > >> As perfectionists, it's always hard to say (and hear) "no" when this sort >> of request comes up. I'm unconvinced it's a serious issue that requires a >> break from normal policy. (Unreported for 2 years in 4 major releases; >> simple workaround present.) >> >> Incidentally, escalating an issue to the steering council after less than >> 24 hours (during a holiday week, no less) probably isn't something we want >> to model as a best practice in forming consensus. >> On Friday, December 30, 2022 at 12:48:47 PM UTC-5 James Bennett wrote: >> >>> I have put it to the Steering Council: >>> >>> >>> https://forum.djangoproject.com/t/request-for-technical-board-steering-council-vote-requested-backport-ticket-34063/17920/1 >>> >> -- > 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/f9fc0dad-fb09-4c5b-8c68-a83375f42d2en%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/f9fc0dad-fb09-4c5b-8c68-a83375f42d2en%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAJwKpySNy2CgG-uEPtJSH5d2bJbUK0WtF-Hgo1u2KFRaOt3Tdw%40mail.gmail.com.
