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'.

Update: Microsoft has confirmed this is a known issue that can be safely ignored. It will not be fixed in SP2007, but is no longer a problem in SP2010.

Capri

Did you discuss this issue with CSS, or report it as a bug? – Regan

Not discussed with Microsoft yet. Trying to gather all the facts first. What is the best place to report this in order to get it to the right person? Congrats on your SPOverflow Score BTW, wonder how long it will take Jaap to get ahead though ;) – Capri

I have now filed this with Microsoft Support. – Capri

Answer 1

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.

Uticas

For now I am filing this under Red Herrings. – Capri

Answer 2

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.

Hyetography

Do you get the problem as well when you rip all your code out of your Activity or using no activities at all in an SPD workflow? Considering I see the error on multiple systems with empty workflows I am starting to think there is no code based solution to this. – Capri

Hmm, it's not too easy to verify now, since we try to avoid SPD workflows (due to deployment complexity in this scenario) and I don't have any workflow without code at the moment. As soon as I'll be creating a new WF, I'll check out for that. – Hyetography

Answer 3

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.

Timikatiming

Can you confirm the same happens on your system? I am not keen to rewrite the standard event receiver that ships with WSS in order to start workflows as our tool is a generic one and should not interfere with existing functionality relied on by other 3rd party solutions. – Capri

Switch reflector to IL language to see what it's doing. It's not really obfuscated; Reflector isn't perfect (yet.) – Polychromatic