I have to deal with multiple signals in golang temporal workflow where signal sending party is a java workflow. I could see that with the help of workflow.GetSignalChannel(ctx, “MySignal”) we can create a signalChannel but that will listen to a particular signal with name “MYSignal”. So I want to handle it dynamically where the signal sending party can send signal Mysignal1 or Mysignal2. I don’t want to use 2 separate channels using GetSignalChannel instead I want to create a chanel var where it will listen to a signal and then with the help of switch case we can compare whether it is a Mysignal1 or Mysignal2 we can take a decision.
How to achieve that in golang. I could see that in java we
could do it with DynamicSignalHandler as shown below.
Workflow.registerListener((DynamicSignalHandler) (signalName, encodedArgs)
Also when I will implement it like:
then it will be a blocking call here then I may loose the other signal.
also How can I make it a continuous workflow which will keep on running and listening to signals forever until an exception occurs
Any pointer to the example would be helpful
In Go you would get two signal channels and listen to both using Selector.
This is similar to using
select statement to listen on two native Go channels.
It would be great if you could share an example which continuously (in some continuous loop with some sleep) listens to 2 different signals
I think the pattern demonstrated in await-signals sample is more applicable to your use case.
The example here deals with the internal workflow , while I am looking for an example where we can send signal from one temopral go workflow and receiving signal on other go workflow so kind of dealing with externalworkflows external signals in go.
Also in the example for await-signals await-signals is the call selector.Select(ctx) a blocking call ie. until we receive signal in signal1 or signal2 or signal3 till then will it wait for signal to receive like select case in pure go channel cases.
If I have to block a workflow such that it should not exit until a cancel request is trigger from the UI and keep on listening in some loop with some predefined delay or sleep than how that can be dealt with