Workflow Services Limitations: Part 5 - A Couple of Updates
In the previous posts in this series, we have observed a couple of weird behaviors around Workflow Services, specifically:
Both of these behaviors have been confirmed.
The suggested workaround for the one-way issue is to release the WCF thread on the service side (by using ThreadPool.QueueUserWorkItem or any similar API).
The race condition scenario is more complicated that I thought. The reason for the problem is that when the WCF message reaches the workflow, the WorkflowOperationInvoker ultimately uses WorkflowInstance.EnqueueItemOnIdle to enqueue the pending work. This works perfectly if there's no idle point between the send activity and the receive activity:
However, if a delay activity is introduced, then the delay potentially causes the workflow to idle before the receive activity has created a queue for the incoming message. As a result, the message is swallowed.
The workaround, as I suggested in the original post, is to ensure the receive activity is scheduled before the workflow goes idle. The parallel paradigm with the receive activity on the left-most branch and the rest of the work in the other branches will ensure this happens at runtime: