Tuesday, March 18, 2014

How to fix SharePoint 2013 Designer list workflows on pages libraries that automatically get cancelled with HTTP 500 exception

What?

List workflows that are built using SharePoint 2013 Designer on pages libraries in SharePoint 2013 get cancelled automatically with internal status "Cancelled" as shown below:



When you click the little icon in blue "i" next to the internal status, you will notice the below:


Details of the error:

RequestorId: 3b5950f5-6aff-ea13-1923-b68a876d73ae. Details: System.ApplicationException: HTTP 500 {"Transfer-Encoding":["chunked"],"X-SharePointHealthScore":["0"],"SPClientServiceRequestDuration":["278"],"SPRequestGuid":["3b5950f5-6aff-ea13-1923-b68a876d73ae"],"request-id":["3b5950f5-6aff-ea13-1923-b68a876d73ae"],"X-FRAME-OPTIONS":["SAMEORIGIN"],"MicrosoftSharePointTeamServices":["15.0.0.4481"],"X-Content-Type-Options":["nosniff"],"X-MS-InvokeApp":["1; RequireReadOnly"],"Cache-Control":["max-age=0, private"],"Date":["Tue, 18 Mar 2014 23:15:24 GMT"],"Server":["Microsoft-IIS\/7.5"],"X-AspNet-Version":["4.0.30319"],"X-Powered-By":["ASP.NET"]} at Microsoft.Activities.Hosting.Runtime.Subroutine.SubroutineChild.Execute(CodeActivityContext context) at System.Activities.CodeActivity.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager 

All other list workflows that  are configured to run on SharePoint lists work just fine

Why?

This is a tricky one to find and to this point I am not sure whether this is the correct work around. This workaround just worked for my scenario and I don't actually propose this is a solution in any way.

I have fiddled with number of things. Who know you might as well try these and you may end up with functioning workflows.

  • Ensure that you are not logged in as system account
  • Re-publish the workflow
  • Make sure that the User profile synchronization has started
  • Ensure that the currently logged in user is picked up by user profile sync
  • Re-register the workflow service using Register-SPWorkflowService –SPSite "http://{server-name}" –WorkflowHostUri "http://{server-name}:12291" –AllowOAuthHttp -Force

None of the above worked for me.

In my case, after fiddling a lot for hours, I figured out that versioning settings on the pages library were the root cause of the problem.

How?

I turned off "Require documents to be checked out before they can be edited" in the pages library's versioning settings page.

Go to the pages library's settings page:




Click on "Versioning Settings"


Make sure that the setting "Require documents to be checked out before they can be edited" is turned off. (It is turned on by default)

Hope this helps someone and please post me the actual resolution if someone is able to identify the root cause for this problem.

1 comment:

  1. Thanks. I struggle with this all day. Turning off require document to be checked out did the trick. Microsoft is doing a poor job of documenting errors.

    ReplyDelete