• Julien Muchembled's avatar
    CMFActivity: slightly delay non-executed grouped messages · c85a840f
    Julien Muchembled authored
    When grouped messages fail, ActivityTool must distinguish 3 groups,
    in order to reexecute them separately, as follows:
    - first, those that succeeded
    - then, those that were skipped
    - at last, failed ones
    
    Grouping methods are updated to handle partial failures, and stop doing
    anything when something goes wrong.
    
    Without this, we would have the following pathological cases.
    
    1. Let's suppose first that skipped messages are marked as succeeded.
    
    The problem is that each skipped message that will fail causes the reexecution
    of those that didn't fail.
    
    Exemple: A:ok B:ok C:err D:err E:err F:err
      1: A:ok, B:ok, C:err, D:skipped, E:skipped, F:skipped
      2: A:ok, B:ok, D:err, E:skipped, F:skipped
      3: A:ok, B:ok, E:err, F:skipped
      4: A:ok, B:ok, F:err
      5: A:ok, B:ok -> commit
    
    And worst, the first failed (C) may be processable again before 5, entering
    a failing loop if it is executed again in the same group as A & B.
    
    2. Another implementation is to mark all skipped as failed.
    
    Example:
      1: A:ok, B:ok, C:err, D:skipped, E:skipped, F:skipped
      2: A:ok, B:ok -> commit
      3: C:err, D:skipped, E:skipped, F:skipped
     >3: same as 3
    
    => D, E or F are never tried.
    c85a840f
RuleTool.py 6.2 KB