Opened 4 years ago

Closed 4 years ago

Last modified 6 months ago

#31508 closed New feature (wontfix)

ASGI Lifespan Support

Reported by: Braunson Owned by: Konstantin Volkov
Component: HTTP handling Version: 3.0
Severity: Normal Keywords: async
Cc: Andrew Godwin, Carlton Gibson, Narbonne Triage Stage: Accepted
Has patch: no Needs documentation: yes
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (16)

comment:1 by Mariusz Felisiak, 4 years ago

Cc: Andrew Godwin Carlton Gibson added

comment:2 by Carlton Gibson, 4 years ago

Component: UncategorizedHTTP handling
Type: UncategorizedNew feature

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

Last edited 4 years ago by Carlton Gibson (previous) (diff)

comment:3 by Carlton Gibson, 4 years ago

Triage Stage: UnreviewedAccepted

comment:4 by Adam Johnson, 4 years ago

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

comment:5 by Carlton Gibson, 4 years ago

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

comment:6 by Andrew Godwin, 4 years ago

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.

in reply to:  2 comment:7 by Braunson, 4 years ago

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.

comment:8 by Carlton Gibson, 4 years ago

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

Last edited 4 years ago by Carlton Gibson (previous) (diff)

comment:9 by Narbonne, 4 years ago

Cc: Narbonne added

comment:10 by Konstantin Volkov, 4 years ago

Owner: changed from nobody to Konstantin Volkov
Status: newassigned

comment:11 by Carlton Gibson, 4 years ago

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

comment:12 by Carlton Gibson, 4 years ago

Needs documentation: set

comment:13 by Carlton Gibson, 4 years ago

Resolution: wontfix
Status: assignedclosed

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.

comment:14 by Carlton Gibson, 4 years ago

Keywords: async added

comment:15 by patrick, 6 months ago

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

in reply to:  15 comment:16 by Carlton Gibson, 6 months ago

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.

Note: See TracTickets for help on using tickets.
Back to Top