Interaction latency API considerations
pyricau opened this issue · 2 comments
Currently an interaction result includes the start and end event.
We should consider simply associating a list of events instead. We'll end up with a single event when start & finish are called on the same event, 2 events for normal delayed interactions, 2 events for normal canceled interactions (but 1 for timed out interactions). We could support more than 3 by having a way to pull a running interaction & associate it to the current event, whether that interaction is running or finishing.
There's separately a question of whether even having an interaction type at all is useful. Since the rules are event based and the events carry all the context needed, an interaction could be defined as a list of events with maybe a name.
To do this we'd likely also need to provide access to all past events associated with a given running interactions, so that you could look them up and find the ones with start ids related to the id of the current event.
One consistent feedback is that cancelRunningInteractions() sounds like it would cancel all interactions when in fact it's all interactions local to the rule. Some have expressed the need to actually do that though, i.e. cancel for a bunch of rules, which might be done by handling all sub rules in a single rule.
An interaction can be thought of as a stream of events. The part that's a bit awkward is converting that stream of events into something that's meaningful and loggable to analytics. If we don't include this part and just report streams of events then consumers still need to have code that recognizes those streams and turn that into something meaningful. Ideally that code would be defined next to where we define which events we care about.
Maybe the running and finishing interactions should have recordEvent() to associate the current event to a stream.
It's a bit confusing that start() is called from the scope and captures the current event, finish() is called from the interaction and also captures the current event, but everything else you have to call recordEvent()
If we start looking at a stream then the interaction type can still be on the rule, and it's something that converts a list of events into an object (also, note, maybe we should have exposed list instead of sequence since we're doing a copy anyway)