Windows Workflow 4.5 Delay Activity Not Persisting

Question

I have a WF4.5 service that I am developing for work, that uses a delay activity in the workflow. The workflow is being hosted in AppFabric (testing locally in Visual Studio). I have my web.config setup in the service and AppFabric is set to use the custom config. Here is an image of the relevent portion of the workflow:

The points to get from the image is that the activity before the delay (Determine Communication) does run and I have verifiable proof of it. I also know that the UpdateRejectionInfo after the delay activity does NOT run (verified with a breakpoint in the custom activity while running the workflow).

I have tried adding a persist activity between the DetermineCommunication activity and the delay activity and it does indeed save to the database where I am looking, so I know the service has write permissions to the database.

Here is the behavior section of the web.config for the service too:

<behaviors>
  <serviceBehaviors>
    <behavior>
      <sqlWorkflowInstanceStore
        connectionString="SERVER=hq-sql02\oculusdev;Database=EAA;Trusted_Connection=yes"
        hostLockRenewalPeriod="00:00:30"
        runnableInstancesDetectionPeriod="00:00:30"
        instanceCompletionAction="DeleteNothing"
        instanceLockedExceptionAction="AggressiveRetry"
        instanceEncodingOption="GZip"/>
      <workflowIdle timeToPersist="00:00:20" timeToUnload="00:00:30"/>
      <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
      <serviceDebug includeExceptionDetailInFaults="true" />
    </behavior>
  </serviceBehaviors>
</behaviors>

Any sort of help would be amazing.

Answer 1

Alright. So the answer to this question goes far beyond the delay activity and gets into other technologies that I am using that I didn't even mention.

TL;DR: I didn't set my entity framework objects to disable lazy loading. So while serializing the data, an exception was thrown that I never saw and it would crash the workflow.

Long Version: When persisting the data to the database, the program tries to serialize all of the objects in your workflow scope. This is normal for standard C# objects, but when they become complex objects, the serialization becomes more complex.

For the ease of technologies, I am using Entity Framework (database-first) in my project to pass and save database entities. When Entity Framework entities are serialized, they try to grab all the information available to it. Well Entity Framework has this idea of lazy loading data, so if you get an entity from the database, and you are looking to get a layer deeper (ie Through a foreign key relationship), it will go back and query the database for that information. Well a common way to get entities from the database is to get the entity and then cut the database connection, through the use of short term using blocks.

If you decide to use the the short term using blocks (what I like to call singleton entities), and you don't turn off lazy loading, then when a program tries to serialize the entity, it will start requesting all the extra data that wasn't grabbed on the initial request. And if that using block has been exited, the database connection will not be available and it will throw an exception.

I was not capturing the exceptions that the built-in activities were throwing, and so it didn't look like it was failing when it really was.