Trigger Signal is tightly bounded to Signaled activity

[pdeki]

Idea to have independent activity allows us to mix and match features/activities and to update/add additional one. Unfortunatelly this is not the case with Trigger Signal and Signaled since source code for Trigger Signal directly invokes the Signal:

protected override async Task<ActivityExecutionResult> OnExecuteAsync(
            WorkflowExecutionContext context,
            CancellationToken cancellationToken)
        {
            var signal = await expressionEvaluator.EvaluateAsync(Signal, context, cancellationToken);
            var input = (await expressionEvaluator.EvaluateAsync(Input, context, cancellationToken)) ?? new Variables();
            var correlationId = await expressionEvaluator.EvaluateAsync(CorrelationId, context, cancellationToken);

            input.SetVariable("Signal", signal);

            await workflowInvoker.TriggerAsync(
                nameof(Signaled),
                input,
                correlationId,
                cancellationToken: cancellationToken
            );

            return Done();
        }

This prevents us to use custom implementation of Signaled activity alone since we need to change both TriggerSignal and Signaled, in pair, to make changes.

Idea: To implement pub/sub where connection between Triggered and Signaled would be used to discover the type of Signaled activity type which will be invoked then.

[sfmskywalker]

I think I see what you mean. Instead of doing workflowInvoker.TriggerAsync from the TriggerSignal activity as seen in your snipper, you want to publish an event (e.g. mediator.Publish(new TriggerSignal())). Then your application could have a handler for that message and chose to trigger workflows using something other than Signaled.

If so, then the question is: should there be a default handler that starts/resumes workflows blocked on Signaled? If yes, and your application adds another event handler to use another type of activity other than Signaled, would that be expected?

In any case, although the Signal/Signaled activities are designed to work together, I would not have any objections to exposing an event when a signal is sent. Or perhaps even more generically; the workflowInvoker.TriggerAsync might publish an event, so that the application can handle more than just the Signaled activity.

Perhaps if you could describe your use case a bit more, it might help me figure out what should be changed to help implement your scenario.