-
Notifications
You must be signed in to change notification settings - Fork 5
Conversation
onEvent: __asyncFunctionGuard(__bindMeta('onEvent')), | ||
onSnapshot: __asyncFunctionGuard(__bindMeta('onSnapshot')), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
onEvent
conveys the read-only nature of this feature well, but maybe not that this is ran at the very end of processing, when the even has been processed by all plugins (as opposed to e.g. a raw event from the endpoint). So maybe something like onCompletedEvent
, onFinishedEvent
, onSavedEvent
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd really like to fight entropy here again :). If we add some modifier, then it's another thing for people to remember, and the entire on
namespace will get annoyingly repetitive. onCreatedEvent
, onCreatedAction
, etc.
People who will know that onEvent
happens after processEvent
because in the interface we'll first have processEvent
plugins that can be reordered, followed by onEvent
plugins that can't be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The UI is not an issue, but this may be unclear from an API perspective for plugin developers. But I don't have a strong opinion on this, so if you definitely see plain onEvent
as the best option, then let's go for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's just document this well :).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the UI, I was getting at the idea that if you're a plugin user, you will see from the UI that there are some plugins that happen in order and some that happen after them. This would lead to some understanding of how to write plugins. However, thinking further, indeed the users and developers won't be the same people (see rudderstack export), so scratch that reasoning. 🤷
* add onEvent and onSnapshot worker tasks * run onEvent and onSnapshot in the two queues, disable processEvent for snapshots * fix some tests * onEvent and onSnapshot are methods in the vm * e2e test for onEvent and onSnapshot for postgres/celery * 3 worker jobs per event now * on* tests for clickhouse e2e * fix clickhouse ingestion bug * extract "ingestEvent" and share between kafka and celery
Changes
onSnapshot
andonEvent
that get run for snapshots and everything else respectivelyonEvent
#328Checklist