Lifespan support

[ferndot]

Lifespan is a new addition to the ASGI specification that provides events pertaining to the main event loop. You can find its documentation here: https://asgi.readthedocs.io/en/latest/specs/lifespan.html

Is there any interest in implementing this in Django Channels?

[andrewgodwin]

How do you see it being implemented? I hadn't really considered doing stuff in Channels with it.

[ferndot]

@andrewgodwin to be honest, I am not entirely sure what all this would entail. I am mostly concerned because ASGI servers like Uvicorn are starting to expect this support and, consequently, break with Django Channels.

I might be interested in using the feature to close a socket used by multiple clients after a specific time, and then expire all their tokens.

[andrewgodwin]

Ah yes, we should at least make Channels just ignore lifecycle requests, though if you have an ApplicationTypeRouter that rejects them the server should be OK with that?

[ferndot]

I think that would be a good place to start. Maybe allow the setting to ignore to be overridden in case the user wants to extend channels to handle lifecycle?

[hongquan]

I think this issue is related to my problem.

In my consumer, I create a aiohttp.client.ClientSession to call external API. When I press Ctrl+C to stop Daphne, I don't know where to put the code to close that ClientSession. As a consquence, I got this error:

^C127.0.0.1:55124 - - [18/Jul/2019:12:30:56] "WSDISCONNECT /ws/card-reader/NFC-205F43" - -
ERROR base_events: Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0x7fe989840dd8>

[carltongibson]

OK, so I'm working on Lifespan support in Daphne right now for django/daphne#264. That'll be this week/next week/some-point-this-summer depending on time available and how it goes.

At that point I'll roll a new Daphne release and cut back to Channels for improvements here. Chunked body handling, proper AGSI 3 support, and, yes, Lifespan are on the list for that. (Any contributions towards that list on the channels end are gratefully received.)

[jheld]

What sort of complexity/challenge do you expect for the channels support? Are some pieces easy enough for first time contributors?

[carltongibson]

Hi @jheld. I don't suppose it'd be all that tricky... The app needs to respond to Lifespan messages... (Receive a startup: process it, return completed or failed... etc). So, a generic consumer to handle Lifespan messages... that folks can subclass to implement the startup and shutdown hooks?

I'd be super-happy to advise if anyone wants to try putting something together.

[jheld]

@carltongibson Fair! Yeah, I'm interested to help implement this (or parts). Sounds fun and looks like it wants to provide sensible ignore (if not using), and those hooks when it does. Would we need an async version of this class, too, or are the hooks intended to be synchronous all the time? If both, perhaps getting the sync version first, and another PR for async (if there is concern around level of effort or complexity).

[carltongibson]

I imagine lifespan events to only need synchronous versions. The server is required to wait for the response before continuing (to serve requests or shutdown as appropriate) so it is effectively blocked anyway...

[jheld]

Cool! Got it. Other than underlying daphne support getting merged (uvicorn would need it, too, separately, I would expect if it doesn't already have it), I could look into this next week, getting a WIP/PoC up.

[carltongibson]

Awesome, thanks. Uvicorn already has support. I'm just trying to get the spare few hours together for the Daphne version. (Soon™ 🙂) If you can pull in a PR here that would be 🎉