Event triggers

Feature RequestAug 6, 2024

Please reintroduce the events feature in V3, similar to what was available in V2.

Trigger with an event name and payload
A task can subscribe to a named event with a filter (it will only create a run if the filter matches)
A single event can trigger many tasks if it matches many

Posted by An Anonymous User · Aug 6, 2024

Anonymous User

•

Aug 6, 2024

Also: With V2 being deprecated, I believe all the main features from V2 should be available in V3.

mattaitken
Team•
Aug 6, 2024
There are some features which are very unlikely to be duplicated in v3 unfortunately. There were some things that weren’t used much or were a bad idea.

The great thing about us being open source is if there is a feature you desperately need that won’t come to v3 you can deploy using one of our self-hosting guides: https://trigger.dev/docs/documentation/guides/self-hosting

Renat Zubayrov

•

Nov 9, 2024

Extremely important! Can’t understand how V3 is not having that!

mattaitken

Team•

Aug 6, 2024

Could you share some more information about your use case?

Do you want events because you want a single event to trigger multiple separate tasks? Or is it because of the filtering? Or something else?

Eugene Terehov
•
Aug 6, 2024
Yes, correct.
We create graphile-worker jobs inside of postgres transactions. This job would fire trigger.dev jobs/tasks (multiple). A graphile-worker job would look like: `public.user:INSERT`.
This way we were able to decouple a lot of business logic rather than adding hooks etc.

So we would have two trigger jobs listening to this event, e.g.
- send email
- set tags
- mattaitken
  Team•
  Aug 6, 2024
  Ok I just want to make sure I understand this:
  - You’re self-hosting Trigger.dev
  - You’re directly inserting jobs into the Graphile tables.
  - Those then get picked up by our Trigger.dev job system as events because the data is in the right format?
  
  If that’s the case it definitely will not work with v3 because we don’t use Graphile as the job queue anymore. It is used for some internal things like scheduling CRON and some cleanup. But it’s not the primary queue that the system uses because it can’t reach the scale we needed, isn’t a fair multi-tenant queue, and doesn’t have proper support for concurrency controls (e.g. per queue concurrency). We have created our own queue built on top of Redis that is used in v3 for the task queue.
  
  We definitely will add events at some point though. That will allow you to trigger with an event name + payload and it will trigger tasks that subscribe to that event.
  
  Right now you can use a different pattern for this where you have a master task and pass a payload with a type in it. Then route to other tasks.
  Eugene Terehov
  •
  Aug 6, 2024
  No, that’s not how we use it.
  
  - We use the cloud version of trigger.dev (so hosted by you guys :-))
  - Essentially all we need is some way to trigger multiple trigger.dev jobs at once, rather than with a handle.
  
  (We use graphile-woker in our system (independent from trigger.dev) to be able to subscribe to Postgres changes inside of a transaction. Graphile-worker than executes a node function, that again would trigger a trigger.dev event - or at least used to do this in V2).

An Anonymous User

•

Nov 8, 2024

We used event triggers extensively in v2. Use case: create a job with webhook trigger, subscribe it to some external system. This job is receiving payload and then fires event with some type and payload. Other jobs can subscribe to needed events in decoupled way.