Context
In a production environment we started to receive, apparently randomly this error message. We have a complex workflow using InfoPath forms developed in Visual Studio, we applied multiple patches by regac-ing new versions of the workflow assemblies, retaining of course the fully qualified names of the assemblies. Also we use a test environment, where regression testing was done by dedicated test engineers.
Shooting in the dark
We found this blog http://geek.hubkey.com/2007/09/locked-workflow.html, which suggested to set the task item workflow version attribbute to 1 (task[SPBuiltInFieldId.WorkflowVersion] = 1;). It solved only temporary the problem, the following access to the task locked again the workflow.
Digging into the sharepoint assemblies, I found out that in Microsoft.SharePoint.dll assembly in the Microsoft.SharePoint.Workflow.SPWinOEItemReceiver class in the ItemUpdating is created the exception causing the "This task is currently locked by a running workflow and cannot be edited" message:
properties.ErrorMessage = SPResource.GetString("WorkflowTaskLocked", new object[0]);
The exception was thrown if the "WorkflowVersion" property of the task created by the workflow was not equal with the value of the PBuiltInFieldId._UIVersion property. In the same method we have:
properties.AfterProperties["WorkflowVersion"] = (int) itemById[SPBuiltInFieldId._UIVersion];
This doesn't make too much sense, the workflow version is set to the the ui version of the task item. The UI version is equal with (512 * major version + minor) version and beacuse in the task list we don't have minor versions, then the ui version is 512 * the version number. I created an ItemUpdating event handler on the task list.
For the from workflows not having this problem (receiving the error message above) the event handler was called two times, first time from the due to the postback from the client browser and second time by the workflow persistence job having elevated privileges. For the workflows having the problem, the second call was not done immediatelly, it was done only on any following user postback by submitting or saving an Info Path form attached to any workflow instance. More than that, we had in the workflow an OnTaskChanged Sharepoint Workflow activity, for which the 'invoked' event was not fired. It was very confusing.
The lucky guess
After hours of digging I restored the workflow assemblies to an older version. Suddenly, some workflows started to run!
In the Wofklows table in the Sharepoint content database, each workflow has a corresponding row, and one of the columns contains the serialisation of that workflow, I think it's a binary serialisation and the rule of thumb is that we deployed patches were the new version of the workflow classes didn't have anymore a 100% binary serialisation match with the already running workflows. We didn't had these problems in the test environments because all the worklows were newly created.
Conclusions
-
the message "This task is currently locked by a running workflow and cannot be edited" didn't suggested at all what was the root cause of the problem, it was totally confusing
-
don't apply patches to the workflow assemblies only if you are sure that the binary serialisation will be 100% compatible with the prevoius versions from the workflow assemblies (no attributes are added or removed from classes etc.)
-
leave in the test environment workflows running from previous versions of patches to catch this kind of exceptions
-
if is possible, version you workflows