Event Loop Protection

Note

You never have to worry about creating loops in your event trigger configuration. This reference is useful if you want to understand why.

The event processor will prevent situations that would otherwise result in never-ending loops of event trigger execution. Event triggers are ignored when any of the following three loop prevention rules apply.

Loop Protection Rules

☑️ LPR1
A given event trigger must ignore events with an originating trigger ID which matches its own trigger ID.

Loop scenario:

• An event trigger T is configured to run a flow for the trigger.event.ok system event
• When this trigger runs, it also creates a trigger.event.ok

☑️ LPR2
A given event trigger must ignore events with a source flow ID which matches its target flow.

Loop scenario:

• A flow has an event node which creates an event with type my.event
• An event trigger exists, which runs the above flow when my.event occurs

This skips an event trigger for events which are directly created by its target flow.

☑️ LPR3
A given event trigger must ignore events with an originating flow ID which matches its target flow

This skips an event trigger for events created as a indirect consequence of the execution of its target flow (e.g. via subflow or event trigger).

Here’s a non-trivial loop scenario that is prevented by this rule:

• A webhook is configured to run flow A
• Flow A runs flow B via a subflow node
• Flow B runs flow C via a subflow node
• Flow C may conditionally create an event with type loopy
• An event trigger T is configured to run flow A for loopy events.

Visually:

When an HTTP request is made to the webhook’s URL;

• Flows A, B and C runs
• Flow C creates the loopy event, which is tagged with:
  • Source flow C
  • Origin flow A
• The loopy event enters the event processor
• The event processor skips the execution of trigger T, because LPR3 is enforced

Troubleshooting

How do you know if loop protection rules are skipping your event triggers?

• Enable debug logging on the server with SIRVEO_LOG_LEVEL=DEBUG
• Restart the server
• Test your flows and event triggers

When a loop protection rule ignores a configured event trigger, server log output will contain:

DBG [events] ignored (loop prevention) event_id=68ba173... rule=LPR1 trigger_id=26ec7a7...
DBG [events] ignored (loop prevention) event_id=fddb2f9... rule=LPR2 trigger_id=67a3fed...
DBG [events] ignored (loop prevention) event_id=10499ed... rule=LPR3 trigger_id=3876c41...

Tip

There’s at least one case where a loop protection rule may interfere with what you’re trying to configure.

Let’s say that you want to run a flow for trigger.event.error system events, which sends you a notification via Slack, Teams, Telegram or email if any event trigger runs a flow with errors. You would simply configure an event trigger to run your notification flow. The edge case is that if your notification flow has an error, LPR1 will skip the event trigger for its own resulting trigger.event.error event. And you won’t be notified that it failed. How do you get notifications in this case? This is a typical monitor-the-monitor problem.

For this particular case, the metadata store comes in handy. If a flow is run by an event trigger, its metadata store will contain some details about the trigger and the event, specifically a event_origin_trigger_id property, which allows a flow to see which event trigger caused it to run.

You will need the internal ID of the event trigger configured for trigger.event.error. Open that trigger in the UI, it’s ID will be in the URL.

• Create a second task
• Add a subflow node to run your notification flow conditionally (or send a different notification, since the main flow failed for some reason):
  • If its a task flow, put the condition in the task level of the subflow node
  • If its a graph flow, put the condition in a JS Condition node, and connect it appropriately
  • Use this condition:
  • $meta.event_origin_trigger_id === '<main trigger ID>'

Then configure a second event trigger for trigger.event.error events, to run your second flow. Which will only forward those events to your main notification flow if the events comes from your main event trigger.

Now you will receive notifications for failing notifications.