Open kdmccormick opened 1 year ago
This has been a problem for certain tasks. See https://edx.readthedocs.io/projects/edx-django-utils/en/latest/monitoring/how_tos/add_code_owner_custom_attribute_to_an_ida.html#handling-celery-tasks for the alternative that avoids the decorator.
@timmc-edx: I don't know if this affects your linting.
It doesn't really affect the linting in edx-platform, no -- it will accept either approach.
Got it, thanks for the alternative. I see now that import_olx and export_olx both use that alternative.
(I'm not sure whether this is an issue with edx-django-utils, with django-user-tasks, or both...)
Adding
@set_code_owner_attribute
and@shared_task
to the same function causes errors when that function is an instance ofUserTask
.For this reason, the import_olx and export_olx tasks in edx-platform do not use
@set_code_owner_attribute
: https://github.com/openedx/edx-platform/blob/db252978f3f315c896b07443f70febdc043faee4/cms/djangoapps/contentstore/tasks.py#L310-L311I recently (accidentally) confirmed this issue... I was working on
update_children_task
in the content_libraries djangoapp, and had this:The celery task did still work, but logs contained a background exception:
Digging in, I found that this key is missing because the django-user-tasks-defined function
arguments_as_dict
was not properly returning a dictionary. The underlying failure seems to be that in the callinspect.getcallargs(cls.run, ...)
,cls.run
does not always actually equal the function defining the celery task (update_children_task
), but rather the stub methodTask.run
. I imagine that this has to do with@set_code_owner_attribute
iterfering with the introspection that@shared_task
and/or django-user-tasks relies upon.I am not exactly sure what the react or impact of this bug is. I do know for sure that developers should not use
@set_code_owner_attribute
on any Django user task function.