Failed to persist workflow instance

Today I noticed the following Unexpected Failed to persist workflow instance messages in my ULS logs:

Failed to persist workflow instance: 95c1ebff-1ebd-4c6e-b254-8dadc03a413e with error code: 5, instance data size: 0, internal state: Locked, Running, processing id: f4c41f01-ecd7-4dac-98fb-fd91a265ca4d

Followed by

Error in committing pending workflow batch items: Microsoft.SharePoint.SPException: Save Conflict. Your changes conflict with those made concurrently by another user. If you want your changes to be applied, click Back in your Web browser, refresh the page, and resubmit your changes. —> System.Runtime.InteropServices.COMException: Save Conflict. Your changes conflict with those made concurrently by another user. If you want your changes to be applied, click Back in your Web browser, refresh the page, and resubmit your changes.0x81020015 at Microsoft.SharePoint.Library.SPRequestInternalClass.AddOrUpdateItem(String bstrUrl, String bstrListName, Boolean bAdd, Boolean bSystemUpdate, Boolean bPreserveItemVersion, Boolean bPreserveItemUIVersi…

According to this article:

http://blogs.technet.com/b/sharepointdevelopersupport/archive/2013/03/12/sharepoint-workflow-architecture-part-3.aspx

One of the causes of this exception is that the workflow was taking too long to finish.  There is a hard-coded threshold in SharePoint that if the workflow is taking more than 20 minutes to reach the next persistence point, its state could be re-set by the fail-over timer job.  We mentioned earlier that this timer job is used to determine if a workflow has died half way through.  If so, it’ll re-set its state.  The way the fail-over timer job detects the dead workflow is to check how long the workflow has been running.  Because most workflows should be able to complete its work within a couple of minutes or even seconds, so if a workflow status in database shows it has been running more than 20 minutes, it’s likely that it’s not running at all.

Solution

So in our case the second message shows the real problem. There are multiple processes trying to update the same item resulting in an update conflict.

To solve this I reviewed my workflows and avoided multiple updates top the same item.

Avatar for Pieter Veenstra

By Pieter Veenstra

Business Applications Microsoft MVP working as the Head of Power Platform at Vantage 365. You can contact me using contact@sharepains.com

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from SharePains by Microsoft MVP Pieter Veenstra

Subscribe now to keep reading and get access to the full archive.

Continue reading