Event semantic

[bcho]

(Maybe issues is not the right place to discuss it, but I don't see the discussion is enabled for this project...)

I am curious what is the reason of making event as unique per queue:

absurd/sql/absurd.sql

Lines 29 to 30 in d68d5dd

	-- without losing context. Events are uniquely indexed and can only be fired
	-- once per name.

. This settings seems making the event system not scalable / useful in scenarios like event based fan-out and event based trigger.

Stealing inngest's doc as example: https://www.inngest.com/docs/guides/fan-out-jobs . For instance, a new app user has finished the main user sign up task. Then, I want to trigger sub tasks like sending out welcome emails / adding to contact. Under current implementation, I cannot use event + payload to trigger them due to a) sub tasks cannot subscribe to a fixed event name like user.signup as it can happen multiple times on different users; b) sub tasks cannot "subscribe" based on user id because it is unknown until the main sign up task has finished. One possible way for making this work is to make the user id as a queue and run these tasks across multiple queues. But I don't think this is a good idea due to scale concern.

I also find it's difficult to come up a concrete example of using event in current settings as it acts like a "one time" thing. Having a way to delete / recreate the event also sounds racy as any task can do this.

I am curious about your thoughts on the semantic of current event setup. To me a better way is to have a pub-sub like experience where I can make my sub tasks to wait on the same event (but we will need to have event based trigger first?) then use the event payload to differentiate on the targets.

Maybe related #46