Tag: Bugs

Intermittent Workflow Error – Failed on start (retrying)

A custom SharePoint 2010 workflow which I wrote was occasionally failing (perhaps 1 in 10) when auto-starting upon the addition of list item with a ‘Failed on start (retrying)‘ status. I’ve dealt with this error in the past and it is almost always caused by invalid workflow code (bad correlation tokens etc, there’s plenty about this elsewhere) but in those cases the failure is consistent.

Looking into the logs I found an unexpected error: “AutoStart Workflow: System.ArgumentException: New instances of this workflow template are currently disallowed“. The workflow association was NOT set to ‘no new instances’. In the case of my particular workflow, it was performing a considerable amount of work upon start including creating a dynamic amount of tasks that in most cases counted more than twenty.

With a lack of other options I modified the workflow with a delay immediately after start so that the workflow would sleep and then create tasks at the next timer interval. The error still intermittently appears in the logs but the workflow runs anyway (I believe it fails to run during the first timer interval when this happens, but retries at the next at which it works). Clearly this solution is not ideal, but has resolved my issue from a functional perspective.

If I come across a more elegant solution or any functional problems with this solution I’ll be sure to update this post. Good luck.

List view sort order bug

SharePoint was once known for it’s unfortunate list of quirky bugs. As of SharePoint 2010 there are definitely less of these to contend with but some still remain – like this one. The sort order for a list view can get rendered incorrectly when editing the view.

When you define a view programmatically it is up to you to create the XML which defines it. A common view query for a tasks list may be to show all items in descending order so that the newest tasks appear at the top of the list. As such:



SPView view = list.Views["All Tasks"];
view.Query = "<OrderBy><FieldRef Name='ID' Ascending='False' /></OrderBy>";
view.Update();

This will update the view just as you or I would expect. However, there is a significant problem here. When a user modifies this view in the future (via the ViewEdit.aspx) the form will show the view is sorted on ID (correct) but the ‘Show items in ascending order’ radio button will be selected (incorrect). If the user now saves the form, perhaps having added another column, the incorrect sort order will be persisted. To avoid this issue you must capitalise the Ascending attribute value as such:



SPView view = list.Views["All Tasks"];
view.Query = "<OrderBy><FieldRef Name='ID' Ascending='FALSE' /></OrderBy>"
view.Update();

I’m unaware of anywhere within SharePoint that providing upper-case boolean attributes is bad practice so I would recommend always using FALSE instead of False and TRUE instead of True.