Re: Backport for ticket 34063?

[Carlton Gibson]

Hey James.

Grrr. 😬

I don't think this justifies an exception to the backport policy. It's not
significantly different from any of any number of other fixes that folks
ask for a backport for and we say no. Fielding "but you backported that
one" isn't an extra task that's going to be helpful.

When I looked at the trace you posted in IRC yesterday, my first thought
was "3.2?". I think supporting Django 3.2 at this point isn't worth
the effort.
Yes, sure it's not EOL for another year or so but if folks want to use
async they should be on the latest version.
There's significant changes still in each version, and sticking on the old
LTS is asking for trouble. (I certainly don't see making exceptions to the
backport policy to help out such to be a good idea. The old LTS is for
frozen apps, not new development.)
You're wanting to add async support to your third-party library: super;
just say it's 4.2+ and move on.
Folks who aren't on the LTS will be updating shortly enough anyway. A
little-bit of carrot never hurt.

Kind Regards,

Carlton

On Fri, 30 Dec 2022 at 01:44, James Bennett  wrote:

> 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
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To 

Re: Backport for ticket 34063?

[James Bennett]

On Fri, Dec 30, 2022 at 12:01 AM Carlton Gibson
 wrote:
> When I looked at the trace you posted in IRC yesterday, my first thought was 
> "3.2?". I think supporting Django 3.2 at this point isn't worth the effort.

It's also broken in 4.0 and 4.1. I just posted the first trace I got
back from my test matrix, which happened to be a Django 3.2 run.

> Yes, sure it's not EOL for another year or so but if folks want to use async 
> they should be on the latest version.

I strongly disagree with this -- Django has been claiming support for
async views/middlewares, and for testing them with AsyncClient, since
3.1. Telling people that actually it was badly broken to the point of
almost unusability until 4.2 and thus not to use any of those versions
that claimed to have the support is... suboptimal. Especially given,
as I noted, the difficulty for Django novices of even figuring out
what the heck is going on when they try to test an async view and get
a weird exception.

Or to put it another way: if I submitted patches against the 3.2, 4.0,
and 4.1 branches for docs/topics/testing/tools.txt that put a big
"WARNING! BROKEN! DO NOT USE!" on all mentions of AsyncClient, I doubt
those patches would be well-received. But that's basically what those
releases of Django *need* at this point. It's intolerably misleading
to end users of the framework to have docs for those versions claiming
that you can write async code and test it with the AsyncClient when...
well, you can't, really, unless you know the precise way that it's
broken and put explicit workarounds for the brokenness in all your
views and middlewares.

> You're wanting to add async support to your third-party library: super; just 
> say it's 4.2+ and move on.

And telling library authors not to even think about doing async
support until Django 4.2 comes out (approximately two and a half years
after Django itself claimed to officially support this stuff), and
that they have to cut off all older versions of Django when they do so
*despite those versions officially claiming to support async* just
seems like a recipe for those authors deciding not to trust or waste
their time on Django.

So I *really* think this one needs an exception to the backports
policy. Async is too important, and Django's reputation is too
important, to leave 3.2, 4.0, and 4.1 as badly broken as they
currently are.

-- 
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/CAL13Cg8ZjzR%3Dzd4PwY%2Bmg1pUMXzPDUx_0ZPetCam5xEM7xqS1w%40mail.gmail.com.

Re: Backport for ticket 34063?

[Carlton Gibson]

James,

All you're talking about is adding this to your test cases right?

# Work around Django #34063 until 4.2.
request.body

# ... continue


C.

On Fri, 30 Dec 2022 at 10:04, James Bennett  wrote:

> On Fri, Dec 30, 2022 at 12:01 AM Carlton Gibson
>  wrote:
> > When I looked at the trace you posted in IRC yesterday, my first thought
> was "3.2?". I think supporting Django 3.2 at this point isn't worth the
> effort.
>
> It's also broken in 4.0 and 4.1. I just posted the first trace I got
> back from my test matrix, which happened to be a Django 3.2 run.
>
> > Yes, sure it's not EOL for another year or so but if folks want to use
> async they should be on the latest version.
>
> I strongly disagree with this -- Django has been claiming support for
> async views/middlewares, and for testing them with AsyncClient, since
> 3.1. Telling people that actually it was badly broken to the point of
> almost unusability until 4.2 and thus not to use any of those versions
> that claimed to have the support is... suboptimal. Especially given,
> as I noted, the difficulty for Django novices of even figuring out
> what the heck is going on when they try to test an async view and get
> a weird exception.
>
> Or to put it another way: if I submitted patches against the 3.2, 4.0,
> and 4.1 branches for docs/topics/testing/tools.txt that put a big
> "WARNING! BROKEN! DO NOT USE!" on all mentions of AsyncClient, I doubt
> those patches would be well-received. But that's basically what those
> releases of Django *need* at this point. It's intolerably misleading
> to end users of the framework to have docs for those versions claiming
> that you can write async code and test it with the AsyncClient when...
> well, you can't, really, unless you know the precise way that it's
> broken and put explicit workarounds for the brokenness in all your
> views and middlewares.
>
> > You're wanting to add async support to your third-party library: super;
> just say it's 4.2+ and move on.
>
> And telling library authors not to even think about doing async
> support until Django 4.2 comes out (approximately two and a half years
> after Django itself claimed to officially support this stuff), and
> that they have to cut off all older versions of Django when they do so
> *despite those versions officially claiming to support async* just
> seems like a recipe for those authors deciding not to trust or waste
> their time on Django.
>
> So I *really* think this one needs an exception to the backports
> policy. Async is too important, and Django's reputation is too
> important, to leave 3.2, 4.0, and 4.1 as badly broken as they
> currently are.
>
> --
> 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/CAL13Cg8ZjzR%3Dzd4PwY%2Bmg1pUMXzPDUx_0ZPetCam5xEM7xqS1w%40mail.gmail.com
> .
>

-- 
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/CAJwKpyQzd%2BUBKWECbHwZvZ37zRRwYh4w9LAMsZFMzqLPvTM5cA%40mail.gmail.com.

Re: Backport for ticket 34063?

[James Bennett]

On Fri, Dec 30, 2022 at 1:09 AM Carlton Gibson  wrote:
> All you're talking about is adding this to your test cases right?
>
> # Work around Django #34063 until 4.2.
> request.body

As far as I can tell it needs to go in whatever code will *read*
request.POST, not the code that generates the request. So that means a
no-op "request.body" in every view and every middleware that might
read request.POST. And that includes Django's own built-in views
(including generic views) and any built-in async-supporting
middlewares, if they have the misfortune to get called on the async
path from an AsyncClient-initiated request.

-- 
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_1MMt2DbcC%2B4Vfzi83g_U-bBNj2-J92Y1NWTvAS9c1Ww%40mail.gmail.com.

Re: Backport for ticket 34063?

[Carlton Gibson]

OK, yes, that's probably right.

Had #34063 been reported during the 3.1 cycle it would have been a release
blocker.
As it was, it wasn't reported until 4.0 (when main was already 4.1) so two
cycles later.
As such it no longer qualifies for a backport.

It's frustrating when this happens, but the backport policy has proven its
worth time and again.
I **really** don't see the case for making an exception here.
(The policy has more value than the inconvenience in any of these cases, or
even all of them summed.)

> As it was, it wasn't reported until 4.0 ...

I think the bottomline is people are only starting to use this stuff now.
It's still experimental, for whatever that means, and there simply are and
will be rough edges.
I'd be very happy to think about how we should message that better — a big
sign saying "Still in development: if you want to use async, be on the
latest versions" would be fine in my opinion.
I think we've been pretty upfront that that's the case.
Adding the support here is difficult and slow enough. Backporting fixes to
discovered bugs, outside the established policy, is making an unrealistic
burden for ourselves.

On Fri, 30 Dec 2022 at 10:13, James Bennett  wrote:

> On Fri, Dec 30, 2022 at 1:09 AM Carlton Gibson 
> wrote:
> > All you're talking about is adding this to your test cases right?
> >
> > # Work around Django #34063 until 4.2.
> > request.body
>
> As far as I can tell it needs to go in whatever code will *read*
> request.POST, not the code that generates the request. So that means a
> no-op "request.body" in every view and every middleware that might
> read request.POST. And that includes Django's own built-in views
> (including generic views) and any built-in async-supporting
> middlewares, if they have the misfortune to get called on the async
> path from an AsyncClient-initiated request.
>
> --
> 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_1MMt2DbcC%2B4Vfzi83g_U-bBNj2-J92Y1NWTvAS9c1Ww%40mail.gmail.com
> .
>

-- 
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/CAJwKpyTCeMvXsxHwENYf0pEw2ySBXOadBEe_EXC04SndSk%3D6bQ%40mail.gmail.com.

Re: Backport for ticket 34063?

[James Bennett]

On Fri, Dec 30, 2022 at 1:27 AM Carlton Gibson  wrote:
> It's frustrating when this happens, but the backport policy has proven its 
> worth time and again.
> I **really** don't see the case for making an exception here.
> (The policy has more value than the inconvenience in any of these cases, or 
> even all of them summed.)

I don't see the value here.

If it's left as-is, the message is, effectively, that Django lied
about its async support for years, but suddenly *now* is asking people
to trust the claims of async support. Unless another major bug gets
found, in which case "well, *now* you can trust Django on async" will
get kicked down the road again.

This is a showstopper of a bug, and just leaving it deliberately
unfixed in *every released version of Django* because "policy said no"
has the potential to do a lot of damage to Django's reputation.

> Adding the support here is difficult and slow enough. Backporting fixes to 
> discovered bugs, outside the established policy, is making an unrealistic 
> burden for ourselves.

I'm not saying every bug found with async needs a backport. But one
that literally prevents the built-in testing tool from working with a
huge swathe of views and middlewares (including potentially some built
in to Django itself), *when that tool is documented and Django claims
to officially support it*, is just unacceptable. I'll work up the
patches myself if that's what it takes.

-- 
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-tMbTXN3WwqjqjgiLj1rrMO6K8YhRHnci6Qzw2d52Y-w%40mail.gmail.com.

Re: Backport for ticket 34063?

[Carlton Gibson]

James,

I think the backport policy has proven itself over the years, no?

"Django lied" — that's a bit melodramatic don't you think?.
Django introduced a new feature, as it is wont to do.
There was a bug in that new feature, as there are wont to be.
Unfortunately that bug was not discovered during the timeframe in which it
would qualify for a backport.
However it's fixed in the upcoming version, which will be in pre-release in
just a couple of weeks.
Sorry for the inconvenience, but backport and supported versions policy is
the foundation of the stability and ease of update you've come to
appreciate in Django over all these years.

> This is a showstopper of a bug...

No it's not. It's a bug in AsyncClient and AsyncRequestFactory, that means
if you're using those on older versions of Django, you'll need to work
around.
This is no different than any of a thousand other cases where there's been
a bug in an older version that folks have needed to account for.

> Unless another major bug gets found...

I'm *quite certain* there are plenty more of these to be found.
The journey is still really only just beginning.
I'd guess I'd say we're entering a new phase, but the async support is
neither complete nor mature.
There will be bugs.

I'm -1 on making an exception to the backport policy in this case. (Sorry I
don't agree with you.)


Kind Regards,

Carlton




On Fri, 30 Dec 2022 at 10:38, James Bennett  wrote:

> On Fri, Dec 30, 2022 at 1:27 AM Carlton Gibson 
> wrote:
> > It's frustrating when this happens, but the backport policy has proven
> its worth time and again.
> > I **really** don't see the case for making an exception here.
> > (The policy has more value than the inconvenience in any of these cases,
> or even all of them summed.)
>
> I don't see the value here.
>
> If it's left as-is, the message is, effectively, that Django lied
> about its async support for years, but suddenly *now* is asking people
> to trust the claims of async support. Unless another major bug gets
> found, in which case "well, *now* you can trust Django on async" will
> get kicked down the road again.
>
> This is a showstopper of a bug, and just leaving it deliberately
> unfixed in *every released version of Django* because "policy said no"
> has the potential to do a lot of damage to Django's reputation.
>
> > Adding the support here is difficult and slow enough. Backporting fixes
> to discovered bugs, outside the established policy, is making an
> unrealistic burden for ourselves.
>
> I'm not saying every bug found with async needs a backport. But one
> that literally prevents the built-in testing tool from working with a
> huge swathe of views and middlewares (including potentially some built
> in to Django itself), *when that tool is documented and Django claims
> to officially support it*, is just unacceptable. I'll work up the
> patches myself if that's what it takes.
>
> --
> 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-tMbTXN3WwqjqjgiLj1rrMO6K8YhRHnci6Qzw2d52Y-w%40mail.gmail.com
> .
>

-- 
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/CAJwKpyQdcKve7rx2fwscf-WTY5c2SzgtaCJeOC66hAbTiMd3dw%40mail.gmail.com.

Re: Backport for ticket 34063?

[James Bennett]

On Fri, Dec 30, 2022 at 2:04 AM Carlton Gibson 
wrote:

> No it's not. It's a bug in AsyncClient and AsyncRequestFactory, that means
> if you're using those on older versions of Django, you'll need to work
> around.
> This is no different than any of a thousand other cases where there's been
> a bug in an older version that folks have needed to account for.
>

I believe it is very different and have explained why repeatedly.

But if it is to be left unfixed, what is the plan for how to communicate
the workaround to people who will be running into this bug until at least
April of 2024? And what is the plan for communicating to them that Django
is aware async testing is broken and the official policy is to knowingly
leave it broken in every currently-released version of the framework? Even
if it will not be fixed for older versions, Django 4.1 ought to be eligible
for a backport. And I strongly urge allowing a backport to 4.0 and 3.2,
though I do not know what could convince you at this point.

This bug is bad. But this response to it is eroding my trust in Django, and
I hope you know that is not something I say lightly. I think it also is
going to erode the trust of other people when they find out about it, and
is going to do so at a critical time when Django is facing stiff
competition in the async space and cannot afford to lose more ground or be
seen as unwilling to support its own claimed async features.

>

-- 
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_5wFeiQjEbOfRYJGgZ2Hn3cQoJHoW-CSUSGD9xuNehoA%40mail.gmail.com.

Re: Backport for ticket 34063?

[Carlton Gibson]

> Even if it will not be fixed for older versions, Django 4.1 ought to be
eligible for a backport.

What you're suggesting is a change to the backport policy. That may be the
right thing to do, but it would be quite a significant change.
These issues — where a bug report/fix comes outside the backport period —
are quite common. It's always a bit frustrating that we can't backport, but
the stability of released versions has been taken (for years, by the whole
community — by the folks hitting the particular non-backported issue this
time :) as correct on balance.

> But this response to it is eroding my trust in Django, and I hope you
know that is not something I say lightly.

Since I'm the only person who's responded thus far, I can't help but read
that as saying it erodes your trust in me. That's sad. Especially since all
I've done is not agree with you. :)
Nonetheless you can invoke the Steering Council if no-one else responds,
and you feel it's as bad as all that.

> ...a critical time when Django is facing stiff competition...

Django's USP is stability and ease of update, not async. The backport,
stability, and supported versions policies are the cornerstone of that, I
believe. It's not something we should endanger.
Other frameworks move faster, but they don't have extended LTS lifetimes to
consider.

I see the success of FastAPI in particular. Super.
But I don't see it as any different to Flask, say, in the previous period.
May a thousand flowers bloom.
I don't see it as an existential threat to Django. Quite the contrary: What
a rich and wonderful time it is for the Python web framework ecosystem as
whole.
(This ecosystem is itself under threat from JavaScript, I'm constantly
told, which will not survive Rust, I hear, ... and so on.)

My view is that Django's async support is maturing nicely, slowly, but
nicely and it's grows every release. That will continue for a few more
cycles yet. Bug fixes in new features should be backported within the
policy yes, but not beyond that. Better guidance in the asynchronous
support docs saying, "hey, do update, this stuff is still growing" may well
be in order. I have this in the Channels 4.0 release notes
:
"The async support in both Python and Django continues to evolve rapidly.
We advise you to always upgrade to the latest versions in order to avoid
issues in older versions if you’re building an async application." — I
don't think similar in Django would hurt. /my view.

> ...as unwilling to support ...

Following the backport policy is not being unwilling to support.

Sorry (again) that I don't share your view. Sorry that undermines your
faith (in me) — I assume we still think there's room for rational
disagreement on how to weigh competing concerns in these kinds of cases.

I'm going to mute this thread until after the new year now.
Enjoy the festivities.

Kind Regards,

Carlton

On Fri, 30 Dec 2022 at 11:34, James Bennett  wrote:

>
>
> On Fri, Dec 30, 2022 at 2:04 AM Carlton Gibson 
> wrote:
>
>> No it's not. It's a bug in AsyncClient and AsyncRequestFactory, that
>> means if you're using those on older versions of Django, you'll need to
>> work around.
>> This is no different than any of a thousand other cases where there's
>> been a bug in an older version that folks have needed to account for.
>>
>
> I believe it is very different and have explained why repeatedly.
>
> But if it is to be left unfixed, what is the plan for how to communicate
> the workaround to people who will be running into this bug until at least
> April of 2024? And what is the plan for communicating to them that Django
> is aware async testing is broken and the official policy is to knowingly
> leave it broken in every currently-released version of the framework? Even
> if it will not be fixed for older versions, Django 4.1 ought to be eligible
> for a backport. And I strongly urge allowing a backport to 4.0 and 3.2,
> though I do not know what could convince you at this point.
>
> This bug is bad. But this response to it is eroding my trust in Django,
> and I hope you know that is not something I say lightly. I think it also is
> going to erode the trust of other people when they find out about it, and
> is going to do so at a critical time when Django is facing stiff
> competition in the async space and cannot afford to lose more ground or be
> seen as unwilling to support its own claimed async features.
>
>> --
> 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_5wFeiQjEbOfRYJGgZ2Hn3cQoJHoW-CSUSGD9xuNehoA%40mail.gmail.com
> 

Re: Backport for ticket 34063?

[James Bennett]

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/CAL13Cg9QdLJBK1K%3D-CO1%2BxvnCbw_X7sCG%2B%2BUSzFv84Jnb8khAA%40mail.gmail.com.

Re: Backport for ticket 34063?

[Tim Graham]

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/7ef540fb-939f-4afa-9e05-33f988f6b0b0n%40googlegroups.com.

Re: Backport for ticket 34063?

[Kevin Grinberg]

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.

Re: Backport for ticket 34063?

[James Bennett]

On Fri, Dec 30, 2022 at 2:24 PM Tim Graham  wrote:
> As perfectionists, it's always hard to say (and hear) "no" when this sort of 
> request comes up.

I wrote a 2,000-word argument explaining why I believe this warrants
backporting. I think that deserves more engagement than just a "no".

> 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.)

I strongly encourage you to read the linked forum post, where I have
explained at length why I think it is serious enough to warrant an
exception (and why I believe the policy should also be
revisited/revised to accommodate cases like this explicitly).

> 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.

Reducing an opposing viewpoint to "it's hard to hear 'no'" probably
falls into that category, too. And I will point out here, as I did in
the forum thread, that the discussion here seemed to be blocked on a
Merger who was not convinced and *who suggested the Steering Council
as an option*. And procedurally, one point of the SC is to serve as a
"court of appeal" if someone cannot convince the Mergers of the merits
of a minor change.

Meanwhile, I think Kevin is pointing in the direction of something
important, which is that it is very easy to wind up in a vicious cycle
where people get the impression that Django does not take its async
story seriously and so they stay away from async Django, which then is
used as an argument for not taking the async story as seriously
(because obviously async Django is not that widely used), which then
gives people the impression...

Async is hard enough without Django making it harder still. So I think
it is important for Django to make clear that the async story is
supposed to be good and that the Django project is committed to
supporting async. Right now, a developer who decides to try out async
Django, with any currently-supported release, and follows the obvious
"how to test my async code" clues in the documentation, will very
likely end up with something broken. Worse: the breakage will be hard
to diagnose, harder to find out the workaround for, and if they do
manage to find it they'll likely also be treated to one or more
threads of the Django project saying that due to the technicalities of
when the breakage was first formally reported, none of the currently
released and allegedly bugfix-supported versions of Django are
actually eligible to receive a fix.

I put it to you that this is not a good experience for the developer,
that it is not the experience the Django project should be inflicting
on the developer, that it will tend to erode the developer's trust and
confidence in Django if this is the path Django decides to take, and
that the solution to all this is comparatively easy: backport the
frankly pretty minimal fix for the async test client into the full set
of currently-supported feature releases of Django as a show of good
faith and support, and to make async support easier for the community
and the overall ecosystem.

-- 
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/CAL13Cg8NAXWw3nLm0TbJH68i8zzgsHGBySJW459KEW81tbY85g%40mail.gmail.com.

Re: Backport for ticket 34063?

[Carlton Gibson]

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 
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
> 
> .
>

-- 
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-Hgo1u2KF