Friday, September 14, 2007

Locked Workflow

I've periodically come across this SPException: "This task is currently locked by a running workflow and cannot be edited" when using the SPWorkflowTask.AlterTask method, even when it seems that the workflow is not in fact locked, and is instead patiently listening for an OnTaskChangedEvent. It turns out that this exception is thrown when the WorkflowVersion of the task list item is not equal to 1, which, if you believe the error message is the same thing as checking to see if the workflow is locked. Only it isn't - apparently sometimes at least, the Workflow version is non zero and the workflow is not locked (the InternalState flag of the workflow does not include the Locked flag bits). I'm not sure why this is occurring - maybe the error message is misleading - but the following code demonstrates a dodgy sort of a workaround that I've found useful. I've no idea if this is a good idea or not, so please treat with skepticism...

18 comments:

Anonymous
said...

Thank you so much for the tip, your code did the trick. I think the reason WorkflowVersion changes is because there's a different version of the workflow dll. So when you recompile your workflow and DLL is changed in the GAC while there are still running workflows, trying to finish any of those workflows might give you "This task is currently locked.." error.

Thank u very very much! With this I was able to resurrect some workflows having randmonly this issue. What I would like is to find out the reason. Why this attribute is left with values like 1024, 8096? It's cleary a flag. I think I will take a look in the WSS 3.0 assemblies to find out when is set.

Hi there, I didn't really know how to implement the code you posted, but I decided to fish around and try some things out manually. I know it's highly frowned upon, but I was able to run some UPDATE queries on the AllUserData table that stored those workflows. I changed the non-1 versions to 1, and it solved my problem (for now). Here's what I did.

Thanks very much for your assistance on this matter. I had to dynamically set a field on the workflow task item which required a item.Update() method call. This update was then causing a lock. By setting the task workflow version back to 1 this removed the problem.

In my case I had this problem on a workflow that was an out-of-the-box MOSS workflow. I found the comment from Mind to be very helpful. Of course this is highly discouraged, but it does seem to work perfectly.

The only thing I would add is that if you hover over your stuck list item in the task list then you will see the ID of the item at the end of the link (bottom left corner). Use this ID and use 'and tp_ID = ####' instead of tp_DirName. This will help ensure that you update only one item at a time (if that's what you want). I figure this is safer than a bulk update. I also checked what would be updating first by running a similar select command first.