The "event" action can be used to generate new events, to be run now or in the future. Events generated like this are considered children of the event responsible for those actions running in the first place. And, in reverse, the original event is considered a parent of each new event.

This strategy is useful for splitting up tasks that would otherwise be long-running, or to establish run order for actions.

When viewing any given event in Mechanic, look in the event details to find any parent or child relationships that apply:

Under "Parent" or "Children", click on a linked event topic to open up a specific event.

Example

To see this in action, try creating a task that looks like this:

Task subscriptions

mechanic/user/trigger
user/fan/out

Task script

{% assign n = event.data | default: 0 | times: 1 %}

{% if n < 5 %}
  {% for m in (0..n) %}
    {% action "event" %}
      {
        "topic": "user/fan/out",
        "data": {{ n | plus: 1 | json }},
        "task_id": {{ task.id | json }}
      }
    {% endaction %}
  {% endfor %}
{% else %}
  {% action "echo" %}
    {
      "event": {{ event | json }}
    }
  {% endaction %}
{% endif %}

As written, this task will "fan out": it will generate 1 child event, which will then generate 2 child events, each of which will then generate 3 child events, and each of those will then generate 4 child events, and finally, each of those events will generate 5 child events of their own. The result: 154 events, created with a single click. :)

And, importantly, note the "task_id" option, applied to the "event" action. This option ensures that only this task will respond to the new event. While it's unlikely that any other task will subscribe to "user/fan/out" events, this option is an important for ensuring expected behavior.

Did this answer your question?