Changes between Initial Version and Version 1 of Ticket #37033, comment 1
- Timestamp:
- Apr 13, 2026, 11:50:40 AM (4 weeks ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #37033, comment 1
initial v1 5 5 > When we re-deploy, we kill the worker containers and re-queue the tasks that were in-flight / ready to process on that worker. 6 6 7 Any reason not to [https://docs.celeryq.dev/en/stable/userguide/workers.html#warm-shutdown perform a warm shutdown] first to limit the cases when this can happen 7 Any reason not to [https://docs.celeryq.dev/en/stable/userguide/workers.html#warm-shutdown perform a warm shutdown] first to limit the cases when this can happen? 8 8 9 9 I'm afraid there's is little Django can do here, if `psycopg2` development halts and it is no longer supported upstream we will have to pull the plug on it. I'm not sure this is the right place to advocate for a problem at the intersection of Celery and psycopg to be solved, have you raised this problem with any of these third party library maintainers? Surely Celery is aware that this signalling approach is problematic (e.g. what if a task is the middle of performing a critical HTTP request when the signal surfaces?) and has documented patterns on how to deal with this problem.