1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
|
# Django Tasks
[](https://github.com/RealOrangeOne/django-tasks/actions/workflows/ci.yml)
An backport of `django.tasks` - Django's built-in [Tasks framework](https://docs.djangoproject.com/en/stable/topics/tasks/).
## Installation
```
python -m pip install django-tasks
```
The first step is to add `django_tasks` to your `INSTALLED_APPS`.
```python
INSTALLED_APPS = [
# ...
"django_tasks",
]
```
Secondly, you'll need to configure a backend. This connects the tasks to whatever is going to execute them.
If omitted, the following configuration is used:
```python
TASKS = {
"default": {
"BACKEND": "django_tasks.backends.immediate.ImmediateBackend"
}
}
```
A few backends are included by default:
- `django_tasks.backends.dummy.DummyBackend`: Don't execute the tasks, just store them. This is especially useful for testing.
- `django_tasks.backends.immediate.ImmediateBackend`: Execute the task immediately in the current thread
Prior to `0.12.0`, [`django-tasks-db`](https://github.com/RealOrangeOne/django-tasks-db) and [`django-tasks-rq`](https://github.com/RealOrangeOne/django-tasks-rq) were also included to provide database and RQ based backends.
## Usage
### Defining tasks
A task is created with the `task` decorator.
```python
from django_tasks import task
@task()
def calculate_meaning_of_life() -> int:
return 42
```
The task decorator accepts a few arguments to customize the task:
- `priority`: The priority of the task (between -100 and 100. Larger numbers are higher priority. 0 by default)
- `queue_name`: Whether to run the task on a specific queue
- `backend`: Name of the backend for this task to use (as defined in `TASKS`)
```python
modified_task = calculate_meaning_of_life.using(priority=10)
```
In addition to the above attributes, `run_after` can be passed to specify a specific time the task should run.
#### Task context
Sometimes the running task may need to know context about how it was enqueued. To receive the task context as an argument to your task function, pass `takes_context` to the decorator and ensure the task takes a `context` as the first argument.
```python
from django_tasks import task, TaskContext
@task(takes_context=True)
def calculate_meaning_of_life(context: TaskContext) -> int:
return 42
```
The task context has the following attributes:
- `task_result`: The running task result
- `attempt`: The current attempt number for the task
This API will be extended with additional features in future.
### Enqueueing tasks
To execute a task, call the `enqueue` method on it:
```python
result = calculate_meaning_of_life.enqueue()
```
The returned `TaskResult` can be interrogated to query the current state of the running task, as well as its return value.
If the task takes arguments, these can be passed as-is to `enqueue`.
### Queue names
By default, tasks are enqueued onto the "default" queue. When using multiple queues, it can be useful to constrain the allowed names, so tasks aren't missed.
```python
TASKS = {
"default": {
"BACKEND": "django_tasks.backends.immediate.ImmediateBackend",
"QUEUES": ["default", "special"]
}
}
```
Enqueueing tasks to an unknown queue name raises `InvalidTaskError`.
To disable queue name validation, set `QUEUES` to `[]`.
### Retrieving task result
When enqueueing a task, you get a `TaskResult`, however it may be useful to retrieve said result from somewhere else (another request, another task etc). This can be done with `get_result` (or `aget_result`):
```python
result_id = result.id
# Later, somewhere else...
calculate_meaning_of_life.get_result(result_id)
```
A result `id` should be considered an opaque string, whose length could be up to 64 characters. ID generation is backend-specific.
Only tasks of the same type can be retrieved this way. To retrieve the result of any task, you can call `get_result` on the backend:
```python
from django_tasks import default_task_backend
default_task_backend.get_result(result_id)
```
### Return values
If your task returns something, it can be retrieved from the `.return_value` attribute on a `TaskResult`. Accessing this property on an unsuccessful task (ie not `SUCCESSFUL`) will raise a `ValueError`.
```python
assert result.status == TaskResultStatus.SUCCESSFUL
assert result.return_value == 42
```
If a result has been updated in the background, you can call `refresh` on it to update its values. Results obtained using `get_result` will always be up-to-date.
```python
assert result.status == TaskResultStatus.READY
result.refresh()
assert result.status == TaskResultStatus.SUCCESSFUL
```
#### Errors
If a task raised an exception, its `.errors` contains information about the error:
```python
assert result.errors[0].exception_class == ValueError
```
Note that this is just the type of exception, and contains no other values. The traceback information is reduced to a string that you can print to help debugging:
```python
assert isinstance(result.errors[0].traceback, str)
```
Note that currently, whilst `.errors` is a list, it will only ever contain a single element.
#### Attempts
The number of times a task has been run is stored as the `.attempts` attribute. This will currently only ever be 0 or 1.
The date of the last attempt is stored as `.last_attempted_at`.
### Backend introspecting
Because `django-tasks` enables support for multiple different backends, those backends may not support all features, and it can be useful to determine this at runtime to ensure the chosen task queue meets the requirements, or to gracefully degrade functionality if it doesn't.
- `supports_defer`: Can tasks be enqueued with the `run_after` attribute?
- `supports_async_task`: Can coroutines be enqueued?
- `supports_get_result`: Can results be retrieved after the fact (from **any** thread / process)?
- `supports_priority`: Can tasks be executed in a given priority order?
```python
from django_tasks import default_task_backend
assert default_task_backend.supports_get_result
```
This is particularly useful in combination with Django's [system check framework](https://docs.djangoproject.com/en/stable/topics/checks/).
### Signals
A few [Signals](https://docs.djangoproject.com/en/stable/topics/signals/) are provided to more easily respond to certain task events.
Whilst signals are available, they may not be the most maintainable approach.
- `django_tasks.signals.task_enqueued`: Called when a task is enqueued. The sender is the backend class. Also called with the enqueued `task_result`.
- `django_tasks.signals.task_finished`: Called when a task finishes (`SUCCESSFUL` or `FAILED`). The sender is the backend class. Also called with the finished `task_result`.
- `django_tasks.signals.task_started`: Called immediately before a task starts executing. The sender is the backend class. Also called with the started `task_result`.
## Contributing
See [CONTRIBUTING.md](./CONTRIBUTING.md) for information on how to contribute.
|
