This will ensure that errors raised by these tasks will alert the right
team. `send_course_enrollment_email` is the one I set out to fix, but I
discovered a few others.
I located tasks that were missing decorators by running the following
search and visually inspecting the results, although semgrep might be able
to do better:
```
ack '^@.*task|^@set_code_owner_attribute' cms lms common openedx xmodule --ignore-dir=tests --python
```
Also, add more detailed explanation of why a couple of tasks can't use the
decorator. This should only be an issue on tasks inheriting from
UserTaskMixin, which in practice is just CourseExportTask and
CourseImportTask (and the apparently unused EnrollmentReadTask and
EnrollmentWriteTask), via UserTask.
The old name was
`student.send_activation_email`.
The new name is now
`common.djangoapps.student.tasks.send_activation_email`.
We no longer user the old task name,
so we can safely stop registering it with Celery
workers, without fear of dropping any lingering
tasks under the old name.
The old name is
`student.send_activation_email`.
The new name is
`common.djangoapps.student.tasks.send_activation_email`.
We currently register both the old and the new task names,
such that Celery workers recognize the task by both names.
This commit switches us from the old name to the new name.
Several tasks are explicitly named as (or like)
their old, deprecated import path.
The issue here is that django-user-tasks listens for task
invocations, and attempts to import the task based on its name.
If the task name is completely wrong, user-tasks will catch
the ImportError and move on.
If the task is a valid *deprecated* import, though, then
user-tasks will choke on the raised `DeprecatedEdxPlatformImportError`.
Thus, we must rename three tasks to their new full path:
1. entitlements.expire_old_enrollments
2. third_party_auth.fetch_saml_metadata
3. student.send_activation_email
The first two are run daily, and so are safe to be
renamed in place.
The third task must be renamed using an expand-contract
pattern; otherwise, we would drop hundreds of tasks
during the App vs. Worker out-of-sync version window
that happens at deployments.
This commit is the expand phase.
* import task decorator from celery APP instance instead of celery package in CMS
* replaced task decorator with shared_task in cms and common
* Fixed import of shared_task
* Fixed import
When rolling out #25477, we dropped hundreds of email activation
tasks due to the renaming of student.send_activation_email
to common.djangoapps.student.send_activation_email,
and lost more when we rolled that PR back.
This happens because of blue/green deployment:
old workers are still online for a while after deploying,
so there is a period of time when the task names are mismatched.
To prevent this from happening again, this will make
it so the import changes don't change the names of
any of the Celery tasks.
