Feature/task panel #2235
Feature/task panel #2235
Conversation
|
|
||
|
|
||
| @task | ||
| def send_welcome_message(message): |
There was a problem hiding this comment.
I would suggest setting up some tasks that follow the Django examples tasks closely:
https://docs.djangoproject.com/en/dev/topics/tasks/
That will help it feel a bit more 'real-world' and may inspire further ideas for functionality in the panel itself :-)
| return render(request, "index.jinja", {"foo": "bar"}, using="jinja2") | ||
|
|
||
|
|
||
| async def async_home(request): |
There was a problem hiding this comment.
I'm not super familiar with this codebase, but when does this view get used?
I'd defer to @tim-schilling and others, but it may make sense to have a dedicated view for triggering off example tasks vs, say, triggering every time you visit an example home page. That could also be a bit more self-documenting and give a place to build off of for the future (like testing larger queues, reporting results on a page template, etc)
| <table> | ||
| <thead> | ||
| <tr> | ||
| <th>Task Info</th> |
There was a problem hiding this comment.
This will need to be wrapped for translation :-)
| try: | ||
| from django.tasks import task | ||
| except ImportError: | ||
| # Define a fallback decorator |
There was a problem hiding this comment.
What are the cases where this could happen? I'm guessing just in older django versions?
Is a fallback decorator a common pattern in this case? I think if its an example meant to work with tasks it shouldn't need a fallback, but I'd be interested to hear more of your thought process. :-)
| "debug_toolbar.panels.cache.CachePanel", | ||
| "debug_toolbar.panels.signals.SignalsPanel", | ||
| "debug_toolbar.panels.community.CommunityPanel", | ||
| "debug_toolbar.panels.tasks.TasksPanel", |
There was a problem hiding this comment.
@tim-schilling I wonder if it would make sense to check for the Django version here, and only include it if its on a Django version that supports the tasks?
| return False | ||
| return True | ||
| except (ImportError, AttributeError): | ||
| return False |
There was a problem hiding this comment.
Is this to be used in the enable_instrumentation method? Seems like it would fit there. The import django can go at the top with the other imports and you can remove the exceptions for that. This project has django as a dependency so it's safe to assume Django is available.
| self._record_task(task, args, kwargs, result) | ||
| return result | ||
|
|
||
| Task.enqueue = wrapped_enqueue |
There was a problem hiding this comment.
This task wrapping looks great. That seems to be the main bits needed to collect stats for the toolbar panel. Nice!
3 participants
Description
This PR creates a panel for Django Tasks to allow the Debug Toolbar to monitor queued tasks.
Fixes #2204
Checklist:
docs/changes.rst.