You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using FastAPI with Uvicorn, and I'm encountering an issue with long-running asynchronous functions in the startup event (@app.on_event("startup")). These functions prevent the program from being interrupted gracefully (e.g., via Ctrl+C), which is critical for my use case where the startup phase includes potentially lengthy operations like setting up database connections or external API calls. This behavior might be related to FastAPI's underlying framework, starlette.
I would like the application to remain responsive to interrupt signals even during the execution of long-running startup tasks. Ideally, it should be possible to stop the server gracefully at any point, including during the startup phase.
I am looking for suggestions or solutions that could help in making the startup_event in FastAPI (possibly influenced by starlette) interruptible. This might include insights into starlette's handling of asynchronous tasks, custom signal handling, event loop management, or any architectural changes that can improve responsiveness to interrupts during startup.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'm using FastAPI with Uvicorn, and I'm encountering an issue with long-running asynchronous functions in the startup event (
@app.on_event("startup")
). These functions prevent the program from being interrupted gracefully (e.g., via Ctrl+C), which is critical for my use case where the startup phase includes potentially lengthy operations like setting up database connections or external API calls. This behavior might be related to FastAPI's underlying framework, starlette.I would like the application to remain responsive to interrupt signals even during the execution of long-running startup tasks. Ideally, it should be possible to stop the server gracefully at any point, including during the startup phase.
I am looking for suggestions or solutions that could help in making the startup_event in FastAPI (possibly influenced by starlette) interruptible. This might include insights into starlette's handling of asynchronous tasks, custom signal handling, event loop management, or any architectural changes that can improve responsiveness to interrupts during startup.
Beta Was this translation helpful? Give feedback.
All reactions