This is a public, read-only report. Striff reads this repository's docs, turns each sentence that makes a claim about the code into a rule, and checks the rule against the code on the default branch. How this works
Each sentence below has a stale name: a type the default branch doesn't declare, or declares somewhere else. Edit the doc so it matches the code, or bring the type back.
Gonecelery.worker.control.ControlDispatch
the current :class:!celery.worker.control.ControlDispatch instance.
celery.worker.control declares nothing by this name.
To use chain, chord or group with tasks called by name, use the :meth:@Celery.signature method:
Celery has a signature method
Holds
Read Oct 2
If you don't have a reference to the task instance you can use :attr:app.current_task <@current_task>:
Celery has current_task
Holds
Read Oct 2
To get the current task being worked on specifically, use :attr:app.current_worker_task <@current_worker_task>:
Celery has current_worker_task
Holds
Read Oct 2
Yes, Use :meth:result.revoke() <celery.result.AsyncResult.revoke>:
AsyncResult has a revoke method
Holds
Read Oct 2
Yes, you can use the Django database scheduler, or you can create a new schedule subclass and override :meth:~celery.schedules.schedule.is_due:
schedule has is_due
Holds
Read Oct 2
Task.retry is used to retry tasks, notably for expected errors that is catch-able with the :keyword:try block.
Task has retry
Holds
Read Oct 2
You can use the eta argument of :meth:Task.apply_async.
Task has apply_async
Holds
Read Oct 2
The :meth:~@AsyncResult.ready method returns whether the task has finished processing or not:
AsyncResult has a ready method
Holds
Read Oct 2
In case the task raised an exception, :meth:~@AsyncResult.get will re-raise the exception, but you can override this by specifying the propagate argument:
AsyncResult has get
Holds
Read Oct 2
To ensure that resources are released, you must eventually call :meth:~@AsyncResult.get or :meth:~@AsyncResult.forget on EVERY :class:~@AsyncResult instance returned after calling a task.
AsyncResult has forget
Holds
Read Oct 2
Celery comes with several utilities useful for presenting the configuration, one is :meth:~celery.app.utils.Settings.humanize:
Settings has humanize
Holds
Read Oct 2
If you instead want to work with the configuration as a dictionary, you can use the :meth:~celery.app.utils.Settings.table method:
Settings has a table method
Holds
Read Oct 2
The result instance also has a :meth:~@AsyncResult.collect method that treats the result as a graph, enabling you to iterate over the results:
AsyncResult has a collect method
Holds
Read Oct 2
:meth:~celery.result.GroupResult.successful
GroupResult has successful
Holds
Read Oct 2
:meth:~celery.result.GroupResult.failed
GroupResult has failed
Holds
Read Oct 2
:meth:~celery.result.GroupResult.waiting
GroupResult has waiting
Holds
Read Oct 2
:meth:~celery.result.GroupResult.ready
GroupResult has ready
Holds
Read Oct 2
:meth:~celery.result.GroupResult.completed_count
GroupResult has completed_count
Holds
Read Oct 2
:meth:~celery.result.GroupResult.revoke
GroupResult has revoke
Holds
Read Oct 2
:meth:~celery.result.GroupResult.join
GroupResult has join
Holds
Read Oct 2
Custom task classes may override which request class to use by changing the attribute celery.app.task.Task.Request:attr:.
Task has a Request field
Holds
Read Oct 2
An application may leverage this facility to add extra observability or side-effects around task failures and timeouts beyond what celery.app.task.Task.on_failure:meth: provides.
Task has on_failure
Holds
Read Oct 2
If you don't care about the results of a task, be sure to set the :attr:~@Task.ignore_result option, as storing results wastes time and resources.
Task has ignore_result
Holds
Read Oct 2
Expected errors (in Task.throws)
Task has throws
Holds
Read Oct 2
Use :meth:~@Task.update_state to update a task's state:.
Task has update_state
Holds
Read Oct 2
This means :meth:AsyncResult.failed() <celery.result.AsyncResult.failed> returns :const:True and the rejection reason is available as the result.
AsyncResult has a failed method
Holds
Read Oct 2
The :exc:~@Retry exception is raised by the Task.retry method to tell the worker that the task is being retried.
Task has a retry method
Holds
Read Oct 2
The :meth:~@Task.run method becomes the task body.
Task has a run method
Holds
29 rules from 5 docs
See these where the change is. The browser extension puts a pull request's doc findings, and a diagram of what it changed, on the GitHub page itself, so the code and what your docs say about it are side by side.
