As mentioned in celery docs, by default result_extended is set to False in the celery config.
But django-celery-results store args, kwargs and other meta info despite result_extended is set to False.
Here are the reproduction steps
# tasks.pyfromceleryimportshared_task@shared_taskdefsome_task(param):
print(f"{param} was passed")
returnparam
Calling the task from django-manage shell
In [1]: frommyapp.apps.niceapp.tasksimportsome_task# calls the taskIn [2]: some_task.delay(["input_2"])
Out[2]: <AsyncResult: ab75a9fb-061c-48a2-a4cb-e85df047e23f># Verifying that `result_extended` is set to `False`In [3]: _2.app.conf.get("result_extended")
Out[3]: False# helper to view all fields in model objectIn [4]: defdisplay_all_fields(s_obj):
...: forfins_obj._meta.fields:
...: print(f.name, getattr(s_obj, f.name))
# Trying to figure out what all info is stored in dbIn [5]: fromdjango_celery_results.modelsimportTaskResultIn [6]: TaskResult.objects.get(task_id=_2.task_id)
Out[6]: <TaskResult: <Task: ab75a9fb-061c-48a2-a4cb-e85df047e23f (SUCCESS)>>In [7]: display_all_fields(_6)
id19096task_idab75a9fb-061c-48a2-a4cb-e85df047e23fperiodic_task_nameNonetask_namemyapp.apps.niceapp.tasks.some_tasktask_args"(['input_2'],)"task_kwargs"{}"statusSUCCESSworkercelery@workcontent_typeapplication/jsoncontent_encodingutf-8result ["input_2"]
date_created2022-05-2407:54:47.677220date_done2022-05-2407:54:47.725070tracebackNonemeta {"children": []}
All the metadata is logged which should be stripped.
Is there a reason to ignore this config option? If not, I would be happy to send in a PR to fix this issue.
Thanks.
The text was updated successfully, but these errors were encountered:
Hi!
As mentioned in celery docs, by default
result_extended
is set toFalse
in the celery config.But django-celery-results store args, kwargs and other meta info despite
result_extended
is set to False.Here are the reproduction steps
Calling the task from
django-manage shell
All the metadata is logged which should be stripped.
Is there a reason to ignore this config option? If not, I would be happy to send in a PR to fix this issue.
Thanks.
The text was updated successfully, but these errors were encountered: