ab6bf348d4
Ticket: BOM-2086 Currently there are parts of the LMS that import content from the CMS APP and vice-versa. When this happens, we end up with 2 instances of the celery app and some tasks get registered to the wrong one. The tasks that were getting registered to the wrong one are never able to run and result in lots of production errors on celery workers. The timing of the CMS celery app instantiation is non deterministic so different tasks get lost depending on when it's imported by some code in the LMS. As long as SERVICE_VARIANT is set, this code should prevent the instantiation of both celery apps.
22 lines
902 B
Python
22 lines
902 B
Python
"""
|
|
Celery needs to be loaded when the cms modules are so that task
|
|
registration and discovery can work correctly.
|
|
"""
|
|
import os
|
|
|
|
# We monkey patch Kombu's entrypoints listing because scanning through this
|
|
# accounts for the majority of LMS/Studio startup time for tests, and we don't
|
|
# use custom Kombu serializers (which is what this is for). Still, this is
|
|
# pretty evil, and should be taken out when we update Celery to the next version
|
|
# where it looks like this method of custom serialization has been removed.
|
|
#
|
|
# FWIW, this is identical behavior to what happens in Kombu if pkg_resources
|
|
# isn't available.
|
|
import kombu.utils
|
|
kombu.utils.entrypoints = lambda namespace: iter([])
|
|
|
|
# This will make sure the app is always imported when
|
|
# Django starts so that shared_task will use this app.
|
|
if os.environ.get('SERVICE_VARIANT', 'lms').startswith('lms'):
|
|
from .celery import APP as CELERY_APP
|