github.com/argoproj/argo-events@v1.9.1/docs/sensors/more-about-sensors-and-triggers.md (about)

     1  # More About Sensors And Triggers
     2  
     3  ## Multiple Dependencies
     4  
     5  If there are multiple dependencies defined in the `Sensor`, you can configure
     6  [Trigger Conditions](trigger-conditions.md) to determine what kind of situation
     7  could get the trigger executed.
     8  
     9  For example, there are 2 dependencies `A` and `B` are defined, then condition
    10  `A || B` means an event from either `A` or `B` will execute the trigger.
    11  
    12  What happens if `A && B` is defined? Assume before `B` has an event `b1`
    13  delivered, `A` has already got events `a1` - `a10`, in this case, `a10` and `b1`
    14  will be used to execute the trigger, and `a1` - `a9` will be dropped.
    15  
    16  In short, at the moment `Trigger Conditions` resolve to true, the latest events
    17  from each dependencies will be used to trigger the actions.
    18  
    19  ## Duplicate Dependencies
    20  
    21  Due to technical reasons when using the NATS Streaming bus, the same `eventSourceName` and `eventName` combo can not
    22  be referenced twice in one `Sensor` object. For example, the following dependency
    23  definitions are not allowed. However, it can be referenced unlimited times in
    24  different `Sensor` objects, so if you do have similar requirements, use 2
    25  `Sensor` objects instead.
    26  
    27  ```yaml
    28  spec:
    29    dependencies:
    30      - name: dep01
    31        eventSourceName: webhook
    32        eventName: example
    33        filters:
    34          data:
    35            - path: body.value
    36              type: number
    37              comparator: "<"
    38              value:
    39                - "20.0"
    40      - name: dep02
    41        eventSourceName: webhook
    42        eventName: example
    43        filters:
    44          data:
    45            - path: body.value
    46              type: number
    47              comparator: ">"
    48              value:
    49                - "50.0"
    50  ```
    51  
    52  Note that this is not an issue for the Jetstream bus, however.
    53  
    54  ## Events Delivery Order
    55  
    56  Following statements are based on using `NATS Streaming` as the EventBus.
    57  
    58  In general, the order of events delivered to a `Sensor` is the order they were
    59  published, but there's no guarantee for that. There could be cases that the
    60  `Sensor` fails to acknowledge the first message, and then succeeds to
    61  acknowledge the second one before the first one is redelivered.
    62  
    63  ## Events Delivery Guarantee
    64  
    65  `NATS Streaming` offers `at-least-once` delivery guarantee. `Jetstream` has additional features that get closer to "exactly once". In addition, in the `Sensor` application, an in-memory cache is implemented to cache the events IDs delivered
    66  in the last 5 minutes: this is used to make sure there won't be any duplicate
    67  events delivered. Based on this, we are able to achieve 1) "exactly once" in almost all cases, with the exception of pods dying while processing messages, and 2) "at least once" in all cases.
    68  
    69  ## Trigger Retries
    70  
    71  By default, there's no retry for the trigger execution, this is based on the
    72  fact that `Sensor` has no idea if failure retry would bring any unexpected
    73  results.
    74  
    75  If you prefer to have retry for the `trigger`, add `retryStrategy` to the spec.
    76  
    77  ```yaml
    78  spec:
    79    triggers:
    80      - template:
    81          name: http-trigger
    82          http:
    83            url: https://xxxxx.com/
    84            method: GET
    85        retryStrategy:
    86          # Give up after this many times
    87          steps: 3
    88  ```
    89  
    90  Or if you want more control on the retries:
    91  
    92  ```yaml
    93  spec:
    94    triggers:
    95      - retryStrategy:
    96          # Give up after this many times
    97          steps: 3
    98          # The initial duration, use strings like "2s", "1m"
    99          duration: 2s
   100          # Duration is multiplied by factor each retry, if factor is not zero
   101          # and steps limit has not been reached.
   102          # Should not be negative
   103          #
   104          # Defaults to "1.0"
   105          factor: 2.0
   106          # The sleep between each retry is the duration plus an additional
   107          # amount chosen uniformly at random from the interval between
   108          # zero and `jitter * duration`.
   109          #
   110          # Defaults to "1"
   111          jitter: 2
   112  ```
   113  
   114  ## Trigger Rate Limit
   115  
   116  There's no rate limit for a trigger unless you configure the spec as following:
   117  
   118  ```yaml
   119  spec:
   120    triggers:
   121      - rateLimit:
   122          # Second, Minute or Hour, defaults to Second
   123          unit: Second
   124          # Requests per unit
   125          requestsPerUnit: 20
   126  ```
   127  
   128  ## Revision History Limit
   129  
   130  Optionally, a `revisionHistoryLimit` may be configured in the spec as following:
   131  
   132  ```yaml
   133  spec:
   134    # Optional
   135    revisionHistoryLimit: 3
   136  ```