When an event is initially published, the Digibee platform begins tracking the number of times this event is triggered between different pipelines or within the same pipeline. This occurrence can be referred to as a “jump.” The event’s lifecycle allows for a maximum of 25 jumps.

To illustrate this concept, consider the following scenario:
​
​

Scenarios where the limit of event lifecycle usage is reached due to infinite loops are uncommon as pipelines typically self-trigger fewer number of times. Instead, lifecycle usage exhaustion is more likely to be caused by a long chain of pipelines, each triggering the next one.

Let’s consider an example to illustrate this concept:
​
​

Even in parallel executions, the event lifecycle is still taken into account. This counting applies to messages generated by both the Event Publisher and Pipeline Executor components.

The scenarios presented here do not depict infinite looping situations. Instead, we assume that logic exists within the pipeline that restricts its unlimited self-triggering. Absence of such control would result in an infinite loop, with the pipeline perpetually triggering itself, potentially causing detrimental effects on system performance. Implementation of this mechanism is essential to manage the event life cycle effectively, thereby preventing looping incidents and preserving optimal realm functionality.
​

​