Browse Source

Do not document the CHORD_PROPAGATES setting anymore

Ask Solem 10 years ago
parent
commit
00ed1e2fee
3 changed files with 2 additions and 33 deletions
  1. 0 23
      docs/configuration.rst
  2. 1 10
      docs/userguide/canvas.rst
  3. 1 0
      extra/release/verify_config_reference.py

+ 0 - 23
docs/configuration.rst

@@ -1218,29 +1218,6 @@ This is the total number of results to cache before older results are evicted.
 The default is 5000.  0 or None means no limit, and a value of :const:`-1`
 The default is 5000.  0 or None means no limit, and a value of :const:`-1`
 will disable the cache.
 will disable the cache.
 
 
-.. setting:: CELERY_CHORD_PROPAGATES
-
-CELERY_CHORD_PROPAGATES
-~~~~~~~~~~~~~~~~~~~~~~~
-
-.. versionadded:: 3.0.14
-
-This setting defines what happens when a task part of a chord raises an
-exception:
-
-- If propagate is True the chord callback will change state to FAILURE
-  with the exception value set to a :exc:`~@ChordError`
-  instance containing information about the error and the task that failed.
-
-    This is the default behavior in Celery 3.1+
-
-- If propagate is False the exception value will instead be forwarded
-  to the chord callback.
-
-    This was the default behavior before version 3.1.
-
-.. setting:: CELERY_TRACK_STARTED
-
 CELERY_TRACK_STARTED
 CELERY_TRACK_STARTED
 ~~~~~~~~~~~~~~~~~~~~
 ~~~~~~~~~~~~~~~~~~~~
 
 

+ 1 - 10
docs/userguide/canvas.rst

@@ -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

+ 1 - 0
extra/release/verify_config_reference.py

@@ -13,6 +13,7 @@ ignore = frozenset([
     'BROKER_PASSWORD',
     'BROKER_PASSWORD',
     'BROKER_VHOST',
     'BROKER_VHOST',
     'BROKER_PORT',
     'BROKER_PORT',
+    'CELERY_CHORD_PROPAGATES',
     'CELERY_REDIS_HOST',
     'CELERY_REDIS_HOST',
     'CELERY_REDIS_PORT',
     'CELERY_REDIS_PORT',
     'CELERY_REDIS_DB',
     'CELERY_REDIS_DB',