[Django] #31508: ASGI Lifespan Support
Django
-----------------------------------------+------------------------
Reporter: braunsonm | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 3.0
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
Hello, I am deploying my website with Uvicorn and I know I get warnings
that ASGI Lifespan is not supported in the Django project.
I was wondering if this was on the roadmap or if I could update the docs
in some way? Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/31508>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------+--------------------------------------
Reporter: Braunson | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 3.0
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by felixxm):
* cc: Andrew Godwin, Carlton Gibson (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:1>
Django
-------------------------------+--------------------------------------
Reporter: Braunson | Owner: nobody
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* type: Uncategorized => New feature
* component: Uncategorized => HTTP handling
Comment:
Hi. I'm inclined to Accept this as a New Feature.
Lifespan is optional (IIUC) but I can imagine folks wanting to use it.
I can't immediately see where the right place for the hooks would be. I
guess I'd start with an ASGI middleware, at least as PoC.
Interested to see what Andrew thinks...?
(Seems a bit keen for uvicorn to **warn** over this, with that whole
''being optional'' thing... 🤔 — I guess you could pass `--lifespan=off`
maybe. )
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:2>
Django
-------------------------------+------------------------------------
Reporter: Braunson | Owner: nobody
Type: New feature | Status: new
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* stage: Unreviewed => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:3>
Django
-------------------------------+------------------------------------
Reporter: Braunson | Owner: nobody
Type: New feature | Status: new
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Adam (Chainz) Johnson):
I know they're unpopular, but seems like an opportunity to use signals?
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:4>
Django
-------------------------------+------------------------------------
Reporter: Braunson | Owner: nobody
Type: New feature | Status: new
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
Hmmm. At least until signal dispatch is async, I'm not sure that's an
option.
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:5>
Django
-------------------------------+------------------------------------
Reporter: Braunson | Owner: nobody
Type: New feature | Status: new
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Andrew Godwin):
The question I would ask first is "why do we need it?". Django already has
somewhat of its own lifespan controls (in `app.ready()` and similar), so I
would want to be sure we are solving a useful problem here rather than
just adding it for the sake of completeness.
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:6>
Django
-------------------------------+------------------------------------
Reporter: Braunson | Owner: nobody
Type: New feature | Status: new
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Braunson):
Replying to [comment:2 Carlton Gibson]:
> Hi. I'm inclined to Accept this as a New Feature.
>
> Lifespan is optional (IIUC) but I can imagine folks wanting to use it.
(Not sure what for exactly but... :)
> I can't immediately see where the right place for the hooks would be. I
guess I'd start with an ASGI middleware, at least as PoC.
>
> Accepting provisionally on that basis. Interested to see what Andrew
thinks...?
>
>
> (Seems a bit keen for uvicorn to **warn** over this, with that whole
''being optional'' thing... 🤔 — I guess you could pass `--lifespan=off`
maybe. )
>
>
That is true, you can manually disable it in uvicorn. There is use cases
for this. One such is Async libraries that only offer asynchronous means
of initialization. For instance Elasticsearch's async calls can be
initialized with `await client.login(...)` for example. If you try to use
the client without this awaited login it will fail.
So a lifespan feature where you could run some async code for constructing
objects would be super useful for me.
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:7>
Django
-------------------------------+------------------------------------
Reporter: Braunson | Owner: nobody
Type: New feature | Status: new
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
Hi Braunson.
Makes sense. Perhaps, for first pass, it would be something we could add
as a middleware to Channels? We could take that easily.
I'm planning a new version there in time for Django 3.1, where even if you
got a PR together right away, it's unlikely this could land in Django
before 3.2 (if at all...)
If such a thing lived in Channels for a while we could see if there was
demand for pulling it into Django.
Fancy taking a pop at it? (Happy to advice...)
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:8>
Django
-------------------------------+------------------------------------
Reporter: Braunson | Owner: nobody
Type: New feature | Status: new
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Narbonne):
* cc: Narbonne (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:9>
Django
-------------------------------------+-------------------------------------
Reporter: Braunson | Owner:
| Konstantin Volkov
Type: New feature | Status: assigned
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Konstantin Volkov):
* owner: nobody => Konstantin Volkov
* status: new => assigned
Comment:
https://github.com/django/django/pull/13636
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:10>
Django
-------------------------------------+-------------------------------------
Reporter: Braunson | Owner:
| Konstantin Volkov
Type: New feature | Status: assigned
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
Hi Konstantin — comments on the PR. It's not clear whether we should
address this, e.g. given Andrew's comment:6.
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:11>
Django
-------------------------------------+-------------------------------------
Reporter: Braunson | Owner:
| Konstantin Volkov
Type: New feature | Status: assigned
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* needs_docs: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:12>
Django
-------------------------------------+-------------------------------------
Reporter: Braunson | Owner:
| Konstantin Volkov
Component: HTTP handling | Version: 3.0
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* status: assigned => closed
* resolution: => wontfix
Comment:
Marking this as wontfix after discussion on the PR. Quoting Andrew:
> still not sure what this offers over app.ready(), so I don't think we
should take this without being really clear what it's solving and then
adding documentation that clears up when to use ready() vs lifespan
events.
Opened #32172 to track making signals async-capable.
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:13>
Django
-------------------------------------+-------------------------------------
Reporter: Braunson | Owner:
| Konstantin Volkov
Type: New feature | Status: closed
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution: wontfix
Has patch: 0 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* keywords: => async
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:14>
Django
-------------------------------------+-------------------------------------
Reporter: Braunson | Owner:
| Konstantin Volkov
Type: New feature | Status: closed
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution: wontfix
Keywords: async | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by patrick):
@Carlton, I know this is an old ticket, but I did find a use case for
myself (but I might be as well doing a bad thing), which is running a
discord bot as soon as the Django app starts. I could use another service
for this, but for my use case this worked fine (with FastAPI at least 😊)
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:15>
Django
-------------------------------------+-------------------------------------
Reporter: Braunson | Owner:
| Konstantin Volkov
Type: New feature | Status: closed
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution: wontfix
Keywords: async | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Carlton Gibson):
As per Andrew’s comment quoted on the resolution, it’s still not clear why
any code run there couldn’t just be done in a `ready` handler.
(Independent of whether either is the best place to do any particular
thing.)
I’d suggest the Forum (see TicketClosingReasons/UseSupportChannels) would
be a better place for further discussion.
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:16>
Django
-------------------------------------+-------------------------------------
Reporter: Braunson | Owner:
| Konstantin Volkov
Type: New feature | Status: closed
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution: wontfix
Keywords: async | Triage Stage: Accepted
Easy pickings: 0 | UI/UX: 0
Comment (by Vašek Dohnal):
I needed lifespan support in Django to make use of HTTP connection pooling
in the HTTPX client. Inspired by the closed pull request
([https://github.com/django/django/pull/13636 django/django#13636]), I put
together an external package, [https://github.com/illagrenan/django-asgi-
lifespan django-asgi-lifespan]. The package works by inheriting from the
standard ASGIHandler and converting lifespan signals to Django signals.
This way, it is possible to create and destroy some shared resource that
is stored in the
[https://asgi.readthedocs.io/en/latest/specs/lifespan.html#lifespan-state
ASGI Lifespan State].
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:17>
Django
-------------------------------------+-------------------------------------
Reporter: Braunson | Owner:
| Konstantin Volkov
Type: New feature | Status: closed
Component: HTTP handling | Version: 3.0
Severity: Normal | Resolution: wontfix
Keywords: async | Triage Stage: Accepted
Easy pickings: 0 | UI/UX: 0
Comment (by jacoobes):
Replying to [comment:17 Vašek Dohnal]:
pooling in the HTTPX client. Inspired by the closed pull request
([https://github.com/django/django/pull/13636 django/django#13636]), I put
together an external package, [https://github.com/illagrenan/django-asgi-
lifespan django-asgi-lifespan]. The package works by inheriting from the
standard ASGIHandler and converting lifespan signals to Django signals.
This way, it is possible to create and destroy some shared resource that
is stored in the
[https://asgi.readthedocs.io/en/latest/specs/lifespan.html#lifespan-state
ASGI Lifespan State].
using psycopg(3).
--
Ticket URL: <https://code.djangoproject.com/ticket/31508#comment:18>