just thought this was strange and it took me a bit of debugging so I thought I'd share.
Suppose you have a workflow that does database updates -- say SqlServer. Now your Sql updates have timeouts. So does your workflow. But these two timeouts are unrelated. If your Sql time out is longer than your workflow one, you can find yourself in the situation that your workflow times out before your query finishes. It's an easy mistake to make, especially if you have multiple people working on it or if you are using some of the default values and it's not obvious what the timeouts are.
There are a series of delegates you set up for workflows: OnWorkflowAborted, OnWorkflowCompleted, OnWorkflowTerminated, etc.
You'd think -- or at least I did -- that one of the delegate methods would fire if the workflow timed out. But it's not true. Instead, the workflow returns false when the wait handle is set. So :
bool Ok = waitHandle.WaitOne(WORKFLOW_TIMEOUT) ;
in case of a time out, Ok is set to false. And that's the only indication that the flow timed out.
So you need to do something like
if (waitHandle.WaitOne(WORKFLOW_TIMEOUT))
...
else // <-- timeout
// do timeout logic.
What I think is even more interesting is that I couldn't find this in any of the sample workflow code I saw on the web. Really, most of it doesn't even set a timeout, which is probably "not optimal" (i.e., "really dumb").
But even the code that does set the time out, never checks to see if it actually has timed out.
Anyway, thought this may help someone sometime, so I'd post it.
--kevin