So, I have a scenario in which I periodically call SignalWorkflowExecution() passing in a request for work flow signalling. In the Decider I have coded, I see it then receive on its next poll request, the signal in the history of events (and a decision task started just after it).
My question is, how do I prevent processing that signal a second time? That is, if I get the signal, then submit a new activity for work, won't the signal still be in the history of events? I don't see a way to correlate the signal with any subsequent decision task, and maintaining state in a Decider is not a recommended practice, since that is what the SWF is intended to be.
Is the Decider expected to also poll other tasklists? That is, if my Decider receives a signal to perform action A, and it then creates a new decision to schedule activity A on tasklist X (where workers for action A are polling), then is the Decider expected to poll tasklist X also to see if an activity has already been scheduled for action A? Otherwise, I don't see how you avoid processing signals over and over again each time it gets a new signal, all the previous signals are in the history, so how do I avoid reprocessing them?
I can't find a lot of info on working with signals. I only see one page, and it doesn't explain how to handle signals in the decider.
I just need to know the "right" way to handle signals in the workflow.
When you are calling PollForDecisionTask, one of the parameters on the response is previousStartedEventId (emphasis added):
The ID of the DecisionTaskStarted event of the previous decision task of this workflow execution that was processed by the decider. This can be used to determine the events in the history new since the last decision task received by the decider.
Generally, each decision task should handle new events since the previous decision task. This is true for more than just signals - it works the same for completed activity tasks, child workflows, cancel requests, etc.