Workflow Foundation: Never finished Delay activity

Let's have a workflow consisted of Receive activity followed by Delay activity. The Receive activity has CanCreateInstance = true and the query (message) correlation is also provided. The workflow is hosted in workflow service and is persisted into the database immediately on idle.

WorkflowService service = new WorkflowService
{
  Name = "MyWorkflow",
  Body = new MyWorkflow(),
  Endpoints =
  {
    new Endpoint
    {
      ServiceContractName = "IMyWorkflow",
      AddressUri = new Uri("http://localhost:1234/MyWorkflow"),
      Binding = new BasicHttpBinding()
    }
  }
};

WorkflowServiceHost host = new WorkflowServiceHost(service);
string conn = "Data Source=...;Initial Catalog=...";
host.DurableInstancingOptions.InstanceStore = new SqlWorkflowInstanceStore(conn);
host.Open();

Now I send the message to the workflow and the runtime creates the first workflow instance. The correlation key is included in the message, of course. The workflow continues with Delay activity and is saved to the database and unloaded.

Let's assume the delay is long enough and I'll send next message with exactly the same correlation key. What happens? Both workflows are never woke up from the delay and never finished.

What do I wrong? Why workflow runtime doesn't protect me against this? Is th开发者_如何学Pythonere any way how to rescue both workflow instances?

Thanks for help!

---

If you are using message correlation the key value in the message must match with a single active workflow. If you try to start a second workflow using the same key you will get an exception when trying to start the new instance. Now if you are using just a Receive without a SendReply you are creating a one way messaging scheme and there is no way to send the SOAP fault back to the client. So the client might not be aware of the error. You can still see this if you turn on tracing in your service and inspect the log files. However the easier option is to include a SendReply, even if you don't have normal response, as this results in a response message that can contain the fault message.