Orphaned Expenses?

May 1, 2009 at 2:34 PM
Awesome sample app! This is just what I needed to dive into these new technologies.

I am confused about the issue of expiring workflows. If I submit a new expense to a Manager and then watch the progression in the Console Host, it will escalate to the Head of Department and after that expire. After the expense escalates it is still visible to the Manager but not the Dept Head, and once the workflow expires I can no longer approve or reject an expense. All I get is an exception stating that the workflow was not found in the state persistence store. Am I missing something?
Jun 19, 2009 at 9:13 AM


Due to the short escalation and expiration duration set in the workflow (for demo purposes), you may encounter this issue. You can check the Auto Refresh check-box to automatically refresh the UI. The Expense row should be removed (otherwise, it is a bug).

When the workflow is left unattended (not approved) it will automatically expire. When that happens, the workflow is considered to be completed. Hence, you get the exception.

Best Regards,

Nov 16, 2009 at 5:55 PM

Along the same line, do you have any suggestions on how to handle the case where: ... ?

1. A workflow is created and submitted for approval.

2. The host app (either Console or in my specific case, Windows Service) is stopped intentionally, maybe for an upgrade or crashes for some reason, so the Workflow never completes.

3. Then you are left with a record in Expense where IsComplete=false, (so it would be displayed in the Approver UI) but no workflow in the Persistant storage.

I'm using concepts from your architecture in an Approval service of my own and I've tried recreating workflow instances for orphan rows without success.  I could just remove them entirely, but then I will have a email notification or similar to communicate to the submitters that will wil have to resubmit.  Any insight you would give would be much appreciated.

Thanks in advance,


Dec 1, 2009 at 10:53 AM

Hi Tony,

I am not very sure what you wanted for #1.

For #2, it is currently up to us to build in the tracking and monitoring. You can make use of the tracking service provided by WF. You may also want to handle the workflow events that are triggered in the host and handle them accordingly. If you configured the persistence service, you should not worry about the workflow not being able to complete because the workflows will continue to run when your host has been restarted. Also, it is recommended that you build in some error handling in your workflows to perform Compensating Actions/Retry or Error Handling when an error occurs. In future, we can rely on Windows Server AppFabric for monitoring.

For #3, the IPendingWork interface in the sample is used to control that problem so that both the persistent storage is synchronized with the database record. Again, you can also consider using error handling in your workflow to handle it.

In any cases, there should not be any orphan rows. If there are, then there must be something wrong somewhere.

Best Regards,