Run on Event
This example assumes we have a task registered on a running worker.
Run-on-event allows you to trigger one or more tasks when a specific event occurs. This is useful when you need to execute a task in response to an ephemeral event where the result is not important. A few common use cases for event-triggered task runs are:
- Running a task when an ephemeral event is received, such as a webhook or a message from a queue.
- When you want to run multiple independent tasks in response to a single event. For instance, if you wanted to run a
send_welcome_email
task, and you also wanted to run agrant_new_user_credits
task, and areward_referral
task, all triggered by the signup. In this case, you might declare all three of those tasks with an event trigger foruser:signup
, and then have them all kick off when that event happens.
Event triggers evaluate tasks to run at the time of the event. If an event is received before the task is registered, the task will not be run.
Declaring Event Triggers
To run a task on an event, you need to declare the event that will trigger the task. This is done by declaring the on_events
property in the task declaration.
Note: Multiple tasks can be triggered by the same event.
Pushing an Event
You can push an event to the event queue by calling the push
method on the Hatchet event client and providing the event name and payload.
Event Filtering
Events can also be filtered in Hatchet, which allows you to push events to Hatchet and only trigger task runs from them in certain cases.
Basic Usage
You can create event filters by using the filters
clients on the SDKs:
Note the scope
argument to the filter. When you create a filter, it must be
given a scope
which will be used by Hatchet internally to look it up. When
you push events that you want filtered, you must provide a scope
with
those events that matches the scope sent with the filter. If you do not, the
filter will not apply.
Then, push an event that uses the filter to determine whether or not to run. For instance, this run will be skipped, since the payload does not match the expression:
But this one will be triggered since the payload does match the expression:
In Hatchet, filters are “positive”, meaning that we look for matches to the filter to determine which tasks to trigger.
Advanced Usage
In addition to referencing input
in the expression (which corresponds to the event payload), you can also reference the following fields:
payload
corresponds to the filter payload (which was part of the request when the filter was created).additional_metadata
allows for filtering based onadditional_metadata
sent with the event.event_key
allows for filtering based on the key of the event, such asuser:created
.