-
-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for retrying tasks in admin #2
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of having a admin action like this in general, but the implementation isn't straight forward and may hide essential errors.
django_celery_monitor/admin.py
Outdated
def retry_tasks(self, request, queryset): | ||
with current_app.default_connection() as connection: | ||
for state in queryset: | ||
module_name, task_name = state.name.rsplit('.', 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should use celery.utils.imports.symbol_by_name
which Celery uses. It's effectively importing kombu's utility of the same name, but it's good to stick with the Celery version of it.
django_celery_monitor/admin.py
Outdated
task.apply_async(**kwargs) | ||
except TypeError: | ||
# it must be a class task | ||
task().apply_async(**kwargs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, class based tasks are essentially dead in Celery 4.x, so it's better to have this raise a TypeError if something goes on during the call of apply_async.
django_celery_monitor/admin.py
Outdated
if task: | ||
kwargs = { | ||
'args': ast.literal_eval(state.args), | ||
'kwargs': ast.literal_eval(state.kwargs), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ast.literal_eval
may work for simple arguments, but it's a different thing for more complex objects that can be serialized but may not be able to evaluated by the ast module. I wonder if there is a way for catching ValueError exceptions or whatever a faulty evaluation may cause and showing to the user in the admin that the retry didn't work because it couldn't parse the arguments? Alternatively, would using Celery's serialization system make this less brittle since we could use it to deserialize the argument values?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TaksState model has args and kwargs defined as TextField (https://docs.djangoproject.com/en/1.11/_modules/django/db/models/fields/#TextField), since args is tuple and kwargs is dictionary they will be converted to strings. An alternative will be to save them in database as json then we can easily decode them and not use literal_eval.
Codecov Report
@@ Coverage Diff @@
## master #2 +/- ##
======================================
Coverage ? 73%
======================================
Files ? 10
Lines ? 426
Branches ? 54
======================================
Hits ? 311
Misses ? 111
Partials ? 4
Continue to review full report at Codecov.
|
In case someone is looking for a Django Admin Action to manually retry Celery tasks, check this |
Hi, I have been using this code to retry tasks from admin within the old django-celery library. Maybe other people will find this useful.