Investigating the root cause behind SharePoint's "request not found in the TrackedRequests"

Question

We have a long standing issue in our bug tracking system about the dreaded "ERROR: request not found in the TrackedRequests. We might be creating and closing webs on different threads." message in SharePoint's trace log.

As we develop Workflow software for the SharePoint market, we look into this issue from time to time to make sure it is not caused by our products. I have personally come to the conclusion that this is a problem in SharePoint, but perhaps someone else can prove me wrong.

Here is what I know:

1. According to the hundreds of search results returned by Google on this topic, this issue appears to be mainly related to SharePoint Workflows, both SharePoint Designer and Visual Studio based workflows.

2. Assuming ULS logging is set to Monitorable, the easiest way to reproduce this problem is to create a new SharePoint Designer Workflow, attach it to a document library, set it to auto start on add/update, don't add any actions, save the workflow and upload a file to the document library.

3. The error is only visible in the SharePoint trace log, it does not appear to impact the execution of the workflow at hand.

4. I have verified that the problem occurs on 32 bit as well as 64 bit systems, Win2K3 and 2K8, WSS and MOSS with SharePoint versions up to the December 2009 Cumulative Update (6524).

5. The problem does not occur when a workflow is started manually.

6. There are dozens of related posts on MSDN Forums, hundreds on Google, one on StackOverflow and none on SharePoint Overflow. There appears to be no answer.

Does anyone have any idea about what is going on, what is causing this and if we should worry or file this under 'Red Herrings'.

Answer 1

This is a really good question and I'm starving to see good responses to this. I've seen this error in my workflows in very different contexts.

For instance, In my case it happens in a home-baked custom activity when I catch the "task created" event and try to "breakroleinheritance" of the SPListItem (the new task).

My custom activity gets workflow context through a property wfActProps which is of type SPWorkflowActivationProperties. Then I typically use wfActProps.Web to access the web object.

The first thought I had that maybe it's a bad tone to pass SPWorkflowActivationProperties between different activities, however I have not found any different way yet.

I'm setting "community wiki" to my answer since this is not an actual answer, rather an example of a situation where this error can be seen.

Answer 2

When I look at the stacktrace (I'm assuming the person who posted that message is referring to the same error), it looks like an OOTB event receiver (Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver) which is responsible for autostarting workflows is disposing an SPSite that may not have been created by the event receiver code.

Unfortunately the AutoStartWorkflow() method is obfuscated so I can't really see in Reflector which SPSite is being disposed. You could experiment writing your own EventReceiver that disposes any existing SPSite it can get it's hands on and see if that causes the same error to be logged.

Answer 3

File it under Red Herrings. You say "The error is only visible in the SharePoint trace log, it does not appear to impact the execution of the workflow at hand." There are so many errors logged in the ULS Log that are beyond our control and do not immediately impact our environment. If you want to improve the product you could attempt a support call that may be non-incremented as a bug. However, what if it's not a bug, but just a verbose ULS Log message?

In fact, this verbosity isn't limited to just the ULS Logs. Have you seen the Microsoft Office SharePoint Server 2007 Management Pack for System Center Operations Manager 2007? It filters out the noise events from the Event Logs on your farm so you can concentrate on the events that flag an actual problem.