f03b141f05
Clearing the RequestCache was intended to address memory leaks in the celery workers. Celery worker processes will process many tasks before they are terminated. RequestCache cleanup typically happens in the RequestCacheMiddleware class, and middleware never executes for celery. To get around that issue, the CLEAR_REQUEST_CACHE_ON_TASK_COMPLETION setting was created to clear the RequestCache after every task was successfully completed. This works fine when celery is running as a separate process, as it's set up to do in production. But during development, the CELERY_ALWAYS_EAGER setting variable is set to True, meaning that celery tasks are run in the same thread as the Django Request. This is meant to make debugging easier, as task failures run as part of the request cycle and will raise exceptions that are visible to the browser. However, celery tasks are triggered from many different actions. That means that the RequestCache was being cleared many times during the course of processing a request. This led to behavior that was potentially slower, but also incorrect–the RequestCache was getting flushed in a way that wouldn't happen in any deployed environment because celery would be running in separate processes there. This came up when trying to fix an issue around extra history records being created during problem submissions: https://discuss.openedx.org/t/extra-history-record-stored-on-each-problem-submission/8081 Furthermore, it's not necessary to prevent RequestCache memory leaks when running in CELERY_AWLAYS_EAGER mode in development because the middleware cleanup happens automatically–as everything is running as part of the request/response cycle. There are times in which we may want to run celery eagerly and still clear the cache, such as testing. I have set CLEAR_REQUEST_CACHE_ON_TASK_COMPLETION = False in all dev and test environments that already have CELERY_ALWAYS_EAGER = True. The unit test that specifically tests whether the request cache is getting cleared upon completion of a celery task then overrides CLEAR_REQUEST_CACHE_ON_TASK_COMPLETION = True even though CELERY_ALWAYS_EAGER = True for the sake of that specific testing purpose.
CMS
===
This directory contains code relating to the Open edX Content Management System ("CMS"). It allows learning content to be created, edited, versioned, and eventually published to the `Open edX Learning Mangement System <../lms>`_ ("LMS"). The main user-facing application that CMS powers is the `Open edX Studio <https://edx.readthedocs.io/projects/open-edx-building-and-running-a-course/en/latest/getting_started/CA_get_started_Studio.html#>`_
See also
--------
* `CMS vs Studio terminology <../docs/decisions/0013-cms-vs-studio.rst>`_
* `CMS vs LMS boundaries <../docs/decisions/0005-studio-lms-subdomain-boundaries.rst>`_