0c57a02119
This should prevent the issues we've seen recently where cms modules are imported by the running lms process, resulting in two celery instances being created and tasks intermittently being registered to the wrong instance (and therefore effectively lost.) In commit ab6bf348d4/PR #25822 we tried to ensure that only one or the other of the instances was created by adding a startup check. Unfortunately, there's an external shared library that refers directly to the lms celery, causing a startup failure in cms, so we had to revert it. Rather than waiting to fix that library, this commit collapses the two instances together so that there is only ever one.
30 lines
908 B
Python
30 lines
908 B
Python
"""
|
|
Import celery, load its settings from the django settings
|
|
and auto discover tasks in all installed django apps.
|
|
|
|
Taken from: https://celery.readthedocs.org/en/latest/django/first-steps-with-django.html
|
|
"""
|
|
|
|
|
|
import os
|
|
|
|
from openedx.core.lib.celery.routers import AlternateEnvironmentRouter
|
|
|
|
# Set the default Django settings module for the 'celery' program
|
|
# and then instantiate the Celery singleton.
|
|
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'lms.envs.production')
|
|
from openedx.core.lib.celery import APP # pylint: disable=wrong-import-position,unused-import
|
|
|
|
|
|
class Router(AlternateEnvironmentRouter):
|
|
"""
|
|
An implementation of AlternateEnvironmentRouter, for routing tasks to non-cms queues.
|
|
"""
|
|
|
|
@property
|
|
def alternate_env_tasks(self):
|
|
"""
|
|
Defines alternate environment tasks, as a dict of form { task_name: alternate_queue }
|
|
"""
|
|
return {}
|