|
@@ -721,11 +721,7 @@ Error handling
|
|
|
|
|
|
So what happens if one of the tasks raises an exception?
|
|
So what happens if one of the tasks raises an exception?
|
|
|
|
|
|
-This was not documented for some time and before version 3.1
|
|
|
|
-the exception value will be forwarded to the chord callback.
|
|
|
|
-
|
|
|
|
-
|
|
|
|
-From 3.1 errors will propagate to the callback, so the callback will not be executed
|
|
|
|
|
|
+Errors will propagate to the callback, so the callback will not be executed
|
|
instead the callback changes to failure state, and the error is set
|
|
instead the callback changes to failure state, and the error is set
|
|
to the :exc:`~@ChordError` exception:
|
|
to the :exc:`~@ChordError` exception:
|
|
|
|
|
|
@@ -743,11 +739,6 @@ to the :exc:`~@ChordError` exception:
|
|
celery.exceptions.ChordError: Dependency 97de6f3f-ea67-4517-a21c-d867c61fcb47
|
|
celery.exceptions.ChordError: Dependency 97de6f3f-ea67-4517-a21c-d867c61fcb47
|
|
raised ValueError('something something',)
|
|
raised ValueError('something something',)
|
|
|
|
|
|
-If you're running 3.0.14 or later you can enable the new behavior via
|
|
|
|
-the :setting:`CELERY_CHORD_PROPAGATES` setting::
|
|
|
|
-
|
|
|
|
- CELERY_CHORD_PROPAGATES = True
|
|
|
|
-
|
|
|
|
While the traceback may be different depending on which result backend is
|
|
While the traceback may be different depending on which result backend is
|
|
being used, you can see the error description includes the id of the task that failed
|
|
being used, you can see the error description includes the id of the task that failed
|
|
and a string representation of the original exception. You can also
|
|
and a string representation of the original exception. You can also
|