1

From time to time, some of my SP2010 site workflows fail with this message:

This task is currently locked by a running workflow and cannot be edited

I believed I have fixed this but from time to time I still get the error.

There is nothing in the logs as to a reason of why this happens. It fails sporadically and I was unable to find a pattern (fails on different tasks, for different users with different access rights, workflow shows as "In progress" etc).

I tried everything I could think of and still nothing. I'm running out of ideas...

How would you approach this situation?

Improve this question
1
  • I have a similar issue (doesnt happened all the time) but happens about 25 to 40% of the time. Using SP 2010. Can anyone please suggest a fix? I can't have c# or powershell (code based) solution.
    – Maria Burton
    Nov 27, 2012 at 17:44

3 Answers 3

Reset to default
1

I assume this is 2007? You could check the number of tasks in your task list which is suggested as one of the causes by the following article: http://social.technet.microsoft.com/wiki/contents/articles/2271.sharepoint-2007-workflow-this-task-is-currently-locked-by-a-running-workflow-and-cannot-be-edited-en-us.aspx

Don't know if that will help.

Improve this answer
3
  • It's in fact 2010
    – JohnDoDo
    May 17, 2012 at 10:22
  • My bad - you do mention it in the opening line of your question: apologies.
    – Steve
    May 21, 2012 at 11:31
  • No need to apologize, in fact I thank you! I updated the question after you mentioned SP 2007. I should have done that from the beginning. It's my bad.
    – JohnDoDo
    May 21, 2012 at 12:15
1

I've come across this before, I think there is a way to check for workflow locks on tasks - checkout the code on this blog post http://geek.hubkey.com/2007/09/locked-workflow.html. I tried to implement this but wasn't successful, hopefully you might have more luck !

Ian.

Improve this answer
1
  • 1
    I know about that workaround, it didn't work for me either. And it is a workaround fix for the effect. I would rather fix the source.
    – JohnDoDo
    May 17, 2012 at 10:28
1

From the way you phrased it, the issue has improved since you tried that fix correct?

If not, or if you just want to be complete in your debugging, I would open up SharePoint Manager 2010 (or download it from codeplex if you don't have it) and check the version of the workflow by navigating to the associated list, as well as looking for anything that was never removed properly.

I have had a strange situation with a client where persisting versions of old code would prevent a proper update to newer code.

And I suppose for the sake of being thorough I would also try to think of extreme situations that might cause your workflow to act oddly (for example, two people approving something at the same time or some such unlikely scenarios) and see if any of your code could break under such a situation.

Hopefully this will at least get you going in a direction to fix it! Sorry i cant give a direct solution, and Good luck

Improve this answer
2
  • I downloaded the SharePoint Manager and I see that the WorkflowVersion of the task item is different than 1. The thing got updated so it's another version for real, but I still can't figure out how that happened. That workaround Ian posted should work but if I don't know HOW it's happening I wouldn't know WHEN to apply it.
    – JohnDoDo
    May 17, 2012 at 14:51
  • check out aarebrot.net/blog/2011/10/…, double update might be relevant, and from what i can tell if you are having trouble with what Ian posted, the purpose is to properly handle an altertask call by effectively overloading it, which in turn is an alternative to update().. Let me know if that makes sense/helps
    – Zork
    May 17, 2012 at 19:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.