diff options
| -rw-r--r-- | doc/source/arguments_and_results.rst | 8 | ||||
| -rw-r--r-- | doc/source/engines.rst | 2 | ||||
| -rw-r--r-- | doc/source/jobs.rst | 2 | ||||
| -rw-r--r-- | doc/source/workers.rst | 4 |
4 files changed, 8 insertions, 8 deletions
diff --git a/doc/source/arguments_and_results.rst b/doc/source/arguments_and_results.rst index a8cc2e5..619a3c4 100644 --- a/doc/source/arguments_and_results.rst +++ b/doc/source/arguments_and_results.rst @@ -87,7 +87,7 @@ Rebinding stored with a name other than the corresponding arguments name. That's when the ``rebind`` constructor parameter comes in handy. Using it the flow author can instruct the engine to fetch a value from storage by one name, but pass it -to a tasks/retrys ``execute`` method with another name. There are two possible +to a tasks/retries ``execute`` method with another name. There are two possible ways of accomplishing this. The first is to pass a dictionary that maps the argument name to the name @@ -303,7 +303,7 @@ Default provides ++++++++++++++++ As mentioned above, the default base class provides nothing, which means -results are not accessible to other tasks/retrys in the flow. +results are not accessible to other tasks/retries in the flow. The author can override this and specify default value for provides using the ``default_provides`` class/instance variable: @@ -386,7 +386,7 @@ A |Retry| controller works with arguments in the same way as a |Task|. But it has an additional parameter ``'history'`` that is itself a :py:class:`~taskflow.retry.History` object that contains what failed over all the engines attempts (aka the outcomes). The history object can be -viewed as a tuple that contains a result of the previous retrys run and a +viewed as a tuple that contains a result of the previous retries run and a table/dict where each key is a failed atoms name and each value is a :py:class:`~taskflow.types.failure.Failure` object. @@ -415,7 +415,7 @@ the following history (printed as a list):: At this point (since the implementation returned ``RETRY``) the |retry.execute| method will be called again and it will receive the same -history and it can then return a value that subseqent tasks can use to alter +history and it can then return a value that subsequent tasks can use to alter their behavior. If instead the |retry.execute| method itself raises an exception, diff --git a/doc/source/engines.rst b/doc/source/engines.rst index 6f16323..e290817 100644 --- a/doc/source/engines.rst +++ b/doc/source/engines.rst @@ -85,7 +85,7 @@ Of course these kind of features can come with some drawbacks: away from (and this is likely a mindset change for programmers used to the imperative model). We have worked to make this less of a concern by creating and encouraging the usage of :doc:`persistence <persistence>`, to help make - it possible to have state and tranfer that state via a argument input and + it possible to have state and transfer that state via a argument input and output mechanism. * Depending on how much imperative code exists (and state inside that code) there *may* be *significant* rework of that code and converting or diff --git a/doc/source/jobs.rst b/doc/source/jobs.rst index 3cd7f95..dbbc6c7 100644 --- a/doc/source/jobs.rst +++ b/doc/source/jobs.rst @@ -215,7 +215,7 @@ Redis **Board type**: ``'redis'`` Uses `redis`_ to provide the jobboard capabilities and semantics by using -a redis hash datastructure and individual job ownership keys (that can +a redis hash data structure and individual job ownership keys (that can optionally expire after a given amount of time). .. note:: diff --git a/doc/source/workers.rst b/doc/source/workers.rst index 95c1559..a2dc941 100644 --- a/doc/source/workers.rst +++ b/doc/source/workers.rst @@ -286,10 +286,10 @@ but not *yet* consumed. **PENDING** - Worker accepted request and is pending to run using its executor (threads, processes, or other). -**FAILURE** - Worker failed after running request (due to task exeception) or +**FAILURE** - Worker failed after running request (due to task exception) or no worker moved/started executing (by placing the request into ``RUNNING`` state) with-in specified time span (this defaults to 60 seconds unless -overriden). +overridden). **RUNNING** - Workers executor (using threads, processes...) has started to run requested task (once this state is transitioned to any request timeout no |