ASGI Lifespan Support

[Braunson]

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.

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

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

[Adam Johnson]

I know they're unpopular, but seems like an opportunity to use signals?

[Carlton Gibson]

Hmmm. At least until signal dispatch is async, I'm not sure that's an option.

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

[Braunson]

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

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

[Konstantin Volkov]

​https://github.com/django/django/pull/13636

[Carlton Gibson]

Hi Konstantin — comments on the PR. It's not clear whether we should address this, e.g. given Andrew's comment:6.

[Carlton Gibson]

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.

[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 😊)

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

[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 (​django/django#13636), I put together an external package, ​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 ​ASGI Lifespan State.