More About Sensors And Triggers¶
If there are multiple dependencies defined in the
Sensor, you can configure
Trigger Conditions to determine what kind of situation
could get the trigger executed.
For example, there are 2 dependencies
B are defined, then condition
A || B means an event from either
B will execute the trigger.
What happens if
A && B is defined? Assume before
B has an event
A has already got events
a10, in this case,
will be used to execute the trigger, and
a9 will be dropped.
In short, at the moment
Trigger Conditions resolve to true, the latest events
from each dependencies will be used to trigger the actions.
Due to technical reasons when using the NATS Streaming bus, the same
eventName combo can not
be referenced twice in one
Sensor object. For example, the following dependency
definitions are not allowed. However, it can be referenced unlimited times in
Sensor objects, so if you do have similar requirements, use 2
Sensor objects instead.
spec: dependencies: - name: dep01 eventSourceName: webhook eventName: example filters: data: - path: body.value type: number comparator: "<" value: - "20.0" - name: dep02 eventSourceName: webhook eventName: example filters: data: - path: body.value type: number comparator: ">" value: - "50.0"
Note that this is not an issue for the Jetstream bus, however.
Events Delivery Order¶
Following statements are based on using
NATS Streaming as the EventBus.
In general, the order of events delivered to a
Sensor is the order they were
published, but there's no guarantee for that. There could be cases that the
Sensor fails to acknowledge the first message, and then succeeds to
acknowledge the second one before the first one is redelivered.
Events Delivery Guarantee¶
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
in the last 5 minutes: this is used to make sure there won't be any duplicate
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.
By default, there's no retry for the trigger execution, this is based on the
Sensor has no idea if failure retry would bring any unexpected
If you prefer to have retry for the
retryStrategy to the spec.
spec: triggers: - template: name: http-trigger http: url: https://xxxxx.com/ method: GET retryStrategy: # Give up after this many times steps: 3
Or if you want more control on the retries:
spec: triggers: - retryStrategy: # Give up after this many times steps: 3 # The initial duration, use strings like "2s", "1m" duration: 2s # Duration is multiplied by factor each retry, if factor is not zero # and steps limit has not been reached. # Should not be negative # # Defaults to "1.0" factor: 2.0 # The sleep between each retry is the duration plus an additional # amount chosen uniformly at random from the interval between # zero and `jitter * duration`. # # Defaults to "1" jitter: 2
Trigger Rate Limit¶
There's no rate limit for a trigger unless you configure the spec as following:
spec: triggers: - rateLimit: # Second, Minute or Hour, defaults to Second unit: Second # Requests per unit requestsPerUnit: 20
Revision History Limit¶
revisionHistoryLimit may be configured in the spec as following:
spec: # Optional revisionHistoryLimit: 3