I think the issue here stems from how you’re thinking of async activities. Dwell and Window are not considered async activities because they don’t have to do any asynchronous work to determine what event to emit to the next downstream task. Dwell might not emit every inbound event to the next downstream task, but it makes that decision synchronously for each event as it arrives.
The tasks that are marked async all have the potential to do database or source operations which we need to wait to complete before we can emit an event to the next downstream task. This includes Procedure execution, Save to Type, Publish to Source, Start Collaboration, and a couple others.
The reason for this distinction has to do with the implementation of Event Streams. Event streams can only process one event at a time (per group if there is an upstream split), so this sort of asynchronous work that we need to wait for can get in the way of the flow of events through the event stream. For these tasks, we do the async work in a rule instead because multiple executions of a rule can occur concurrently. The consequence of this is that when the event hits the rule it effectively hits the end of a chain of event streams. Split By Group persists as long as you remain in a chain of event streams, however as soon as you put a rule in the middle you’ve broken that chain, and the split doesn’t persist after the rule on to the next downstream task.
Now about Transformation: Transformation is intended to be used to do in-memory transformations that do not require expensive operations. It’s possible to abuse this activity pattern by putting expensive operations in your transformations, in which case you won’t get the throughput you want through the transformation task, but we don’t stop you from making that bad decision. If you want to do expensive transformation-like things that require DB operations you can always use the Procedure activity pattern, which as you noted is async.
I think the issue here stems from how you’re thinking of async activities. Dwell and Window are not considered async activities because they don’t have to do any asynchronous work to determine what event to emit to the next downstream task. Dwell might not emit every inbound event to the next downstream task, but it makes that decision synchronously for each event as it arrives.
The tasks that are marked async all have the potential to do database or source operations which we need to wait to complete before we can emit an event to the next downstream task. This includes Procedure execution, Save to Type, Publish to Source, Start Collaboration, and a couple others.
The reason for this distinction has to do with the implementation of Event Streams. Event streams can only process one event at a time (per group if there is an upstream split), so this sort of asynchronous work that we need to wait for can get in the way of the flow of events through the event stream. For these tasks, we do the async work in a rule instead because multiple executions of a rule can occur concurrently. The consequence of this is that when the event hits the rule it effectively hits the end of a chain of event streams. Split By Group persists as long as you remain in a chain of event streams, however as soon as you put a rule in the middle you’ve broken that chain, and the split doesn’t persist after the rule on to the next downstream task.
Now about Transformation: Transformation is intended to be used to do in-memory transformations that do not require expensive operations. It’s possible to abuse this activity pattern by putting expensive operations in your transformations, in which case you won’t get the throughput you want through the transformation task, but we don’t stop you from making that bad decision. If you want to do expensive transformation-like things that require DB operations you can always use the Procedure activity pattern, which as you noted is async.