Also if a celery worker service does a redeployment.
And the celery worker is doing work, does the work disappear if a redeployment happens?

i think the best way here is to simply provision however many replicas and the concurrency levels you would need at your theoretical max job throughput.

likely by default the celery worker would pick back up any unfinished jobs, its a task worker, surely it has built in fault tolerance, but during a new deployment Railway sends sigterm, waits 3 seconds (configurable) and then kills the container, so as long as celery respects the sigterm and stops accepting jobs and then finishes the in flight jobs then you are fine.

ok I see.

So this is more of a celery problem rather than a railway.app problem.

I do believe celery has some configuration that I need to figure out. Because right now, if I do a redeployment, all celery workers die, and new ones get spawned, and the tasks that were being worked on by the dead celery workers will become invisibile on the broker, unless enough time passes, depending on the configuration, and will become visibile again on redis.

So if I do a redeployment, and if I configure my celery workers correctly, all that should happen is that the work ends up being delayed by a few hours, instead of disappearing.

i think there would be further problems with the celery config if work is delayed a few hours after a redeploy, but yes you are on the right track

!s