Flow Framework: How does @Signal behave and can be used to perform some dynamic tasks, which change the execution flow in SWF

Question

Some of my observations on researching about flow framework are:

@Signal starts executing in the decider replay once the signal is received. @Signal method is executed in all the future replays of the same workflow. (Once signal is received, on each replay the decider executes @Signal). @Asynchronus methods should not be long running tasks, as decider will schedule Activity Tasks only after all @Asynch methods have completed execution.

Are my observations correct ? If yes: then what if in the same workflow I want a signal, which performs some task and then stop executing for future replays. Such as a pause signal: user might pause and resume a workflow multiple times.

Another problem is: How are the following types of cases handled by flow: A decider times out, and meanwhile two events come: Cancel workflow and Activity Completed. How does decider figure out that they are related and if cancellation is done, then do not responds to ActivityComplatedEvent.

Answer 1

It helps to not think about workflow behavior in terms of replay. Replay is just a mechanism for recovering workflow state. But when workflow logic is written it is not really visible besides the requirement of determinism and that workflow code is asynchronous and non blocking. So never think about replay when designing your workflow logic. Write it as it is a locally executing asynchronous program.

So when replay is not in a way the @Signal is just a callback method that executes once per received signal. So if you invoke some action from the @Signal method then it is going to execute once.

As for second question it depends on the order in which cancellation and activity completion are received. If cancellation is first then cancellation is delivered to a workflow first which might cause the cancellation of the activity. Cancellation is actually blocking waiting for activity to cancel. Completion of activity (which is the next event) unblocks the cancellation for it. If completion is second then activity completes and whatever follows it is cancelled by the next event. In majority of cases the result is exactly the same that activity completion is received but all logic after that is cancelled.