Unexpected signal processing between state

[Ranc20]

Hi, i'm trying to debug some unexpected behaviour in the running workflow.

Workflow simplified flow :
Workflow A has state B and C. State B wait for signal D and State C wait for signal E.
If state B received a signal it will process some data and move to state C.
if state C received a signal it will process some data and move to state B.
the flow will go back and forth between these two state before the workflow finish.

there is an unexpected case where state B is signaled more than one signal D. The state move properly to next state (state C), but after state C completed the task and move to state B again, state B will directly processed the data without waiting the signal first like it should.

why this behaviour happen ?

Thanks.

[Ranc20]

@longquanzheng

[longquanzheng]

state B will directly processed the data without waiting the signal first like it should.

Just to confirm, in the history you still see the “waitUntil” activity executed but it just got unblocked immediately because of existing message in the channel (due to duplicate publishing). Is that correct?

if so, here is the explanation:

A Signal(or internal) channel and their messages belong to the whole workflow execution, not for a particular state or state execution. even you only have a single state waits for the channel, the remaining messages will stay in the channel for future consumption.

I guess your expectation is that, when state B waits for the channel, it will take all messages, clearing the channel so that next time it will wait for new messages.

Ideally, the waitUntil command should let you wait And take all available messages. This is not supported yet in this ticket #301 the ticket also suggests a workaround by using anyCommandCombination feature

It’s a pretty good use case for this ticket ! Thanks for sharing that. We probably should build that feature (it’s a pretty small one IMO)

Hope it helps . And thanks for using iWF.

[longquanzheng]

To get deeper into the problem, I am curious why there are duplicate signals at all in the environment. Is that because there are multiple senders and you don’t check before sending? Or it’s because the server could timeout the requests and caused retry?

Either way, a good option is to use RPC + internalChannel + data attribute to replace the signal channel. This will avoid the duplicate from happening.

Basically , you can use a Boolean flag as data attribute to check if the channel already has a message. If so, then RPC just return without doing anything. If not, then sending a message to internal channel and update the flag. Then state B will flip the flag back after it consumes the message.

[longquanzheng]

@Ranc20 let me know if you need more help

[Ranc20]

Just to confirm, in the history you still see the “waitUntil” activity executed but it just got unblocked immediately because of existing message in the channel (due to duplicate publishing). Is that correct?

yes, that's correct.

I guess your expectation is that, when state B waits for the channel, it will take all messages, clearing the channel so that next time it will wait for new messages.

yes, i expect that way.

This is not supported yet in this ticket #301 the ticket also suggests a workaround by using anyCommandCombination feature

i dont think anyCommandCombination feature will solve my issue, because i dont know for sure how many time the unexpected signal will be fired. And it is using the same channel name.

Workflow A has state B and C. State B wait for signal D and State C wait for signal E.

There might be duplicate signal D or E, so i cant tracked or differentiate using channel name

To get deeper into the problem, I am curious why there are duplicate signals at all in the environment. Is that because there are multiple senders and you don’t check before sending? Or it’s because the server could timeout the requests and caused retry?

There should be only one sender, but there is a chance that sender hit the function again multiple time before my status got updated. In the happy flow, that status should prevent the signaling process.

Basically , you can use a Boolean flag as data attribute to check if the channel already has a message. If so, then RPC just return without doing anything. If not, then sending a message to internal channel and update the flag. Then state B will flip the flag back after it consumes the message.

How i drained / dumped all unprocessed messages ? because that duplicate signal shouldnt be processed at all.

Thanks for your explanation.

[longquanzheng]

Also, may I ask what is your business use case behind this? It may be better to understand to help you use the best solution.

[Ranc20]

Im using golang sdk for this scenario.

This workflow scheme is used to support price negotiation between parties. And the negotiation length is dynamic i cant limit for how long.

[longquanzheng]

This workflow scheme is used to support price negotiation between parties. And the negotiation length is dynamic i cant limit for how long.

Can you elaborate on how it related to duplicate signals and stateB and C?

[Ranc20]

State B will handle negotiation from person 1
State C will handle negotiation from person 2

If state B signaled it will process some data, and move to state C waiting for person 2.

the duplicate signal can occur when person 1 / 2 send the negotiation more than one simultaneously.

[longquanzheng]

Got it . The above RPC approach should work. It will prevent sending duplicate signal if not the person’s turn