Celery breaks upgrading from 4.4.6 to 4.4.7

[jskitz]

What happened?

The requirements in Django Cookie Cutter changed Celery from 4.4.6 to 4.4.7 recently. I upgraded my projects that were based off of this project, and then I could no longer get my tasks to be pulled in to production. There is more on this issue in Celery issues

What should've happened instead?

Production tasks should have been properly registered as tasks. Instead, when you invoke tasks in production, it says that there are no registered tasks. This can be verified by running celery from an init.d script, opening a shell on production, and executing the following tasks:

from celery.task.control import  inspect
i = inspect()
i.registered_tasks()

Additional details

• Host system configuration:

  • Celery is run on ubuntu via an init script generating a command like the following: celery -c /home/ubuntu/venv/bin/celery multi start w1 --workdir=/home/ubuntu/project --pidfile=/var/run/celery/%n.pid --logfile=/var/log/celery/%n%I.log --loglevel=INFO --app=config.celery_app --time-limit=300 --concurrency=4. This will not pass the --app=config.celery_app to the workers.
  • Version of cookiecutter CLI (get it with cookiecutter --version): 1.7.2
  • OS: Problem happens using production settings but not local settings.
  • Python version: 3.8
  • Docker versions (if using Docker): N/A

• Options selected and/or replay file: Choosing Celery with the latest build of django-cookiecutter will use 4.4.7 instead 4.4.6 which exhibits the problem.

The solution is simply to downgrade to Celery 4.4.6 until Celery pushes out a new version. Posting here to save other people a lot of time and headaches trying to debug what was happening with this recent upgrade.

[browniebroke]

I saw this issue in Celery a few days ago, but didn't get around to fix it here. We should definitely downgrade if it's affecting us.

[Andrew-Chen-Wang]

Actually this is pretty interesting. The fix is using CELERY_APP as an environment variable, according to that repo, for now (which happens to be in the entrypoint file) since I didn't realize that my celery 4.4.7 on Docker was working fine. This may just be a local setup issue.

Although tbf, I've been having all sorts of issues lately with Celery > 4.4.2 after some string of commits messed up the celery multi command which ended up messing up a lot of things afterwards.

[arnav13081994]

@Andrew-Chen-Wang I think you're right about that. All those inspect tasks fail to be registered iff flower gets started before celery. Somehow that wasn't an issue before 4.4.6 perhaps because of that env var you mention but I have no idea about that.

To resolve the issue, I added a custom script that waits for 1 or more celery workers to be online and only then the flower service gets started. And so far everything seems to be working fine.

Also, celery 5.0.0 has quite a few breaking changes ....