Jason Specland: Consultant, Comedian

Making it up as I go along. Always.

Adventures in Uninformative SharePoint Messages, or The Sandbox is Too Damn Busy for Your List Receiver

Still here? Great. So, here’s the situation. Tell me if it seems crazy. There are things that, to me as a programmer, don’t seem crazy at all, while more seasoned SharePoint developers would look at what I was doing and scream, “Are you mad?” Like iterating through SPList.Items() in a foreach loop without first putting them into an SPListItemCollection, for example.

Anyway, I have the following situation: A project tracking list, which has a “Primary Technical Lead” field and a “Secondary Technical Lead” field, both of which are single User-type. I need to create a “Team Members” field, which is a multi-User type. Upon creation of that field, I need to populate it with both the value from the Primary and Secondary tech lead fields. Naturally, I chose to implement this one-time setup in the FeatureActivated event receiver.

Additionally, I want to make sure that whenever a tech lead is changed, that that change is reflected in the Team Members field. I also want to make sure that you can’t delete someone from Team Members if they’re still a tech lead. Naturally, I chose to implement this as an ItemUpdating event receiver.

Every time I tried to activate the solution, however, I always got the following error:

Unhandled exception was thrown by the sandboxed code wrapper’s Execute method in the partial trust app domain: The sandboxed code execution request was refused because the Sandboxed Code Host Service was too busy to handle the request.

Well, excuuuuuuuuse me!

Now, I wasn’t entirely un-clever about this. Of course my ItemUpdating event was firing when I was trying to populate the TeamMembers field. (Okay, I’m kind of lying. There was a lot of blank “WTF?” going on in my head before I realized that the ItemUpdating event was firing. Then I went through the feature activation in the debugger, and noticed that the exception was thrown when I called SPListItem.Update() or SPListItem.SystemUpdate(), which I tried in desperation.) But my ItemUpdating method should have just quickly exited upon not seeing the fields that it was worried about in the AfterProperties. Still, worried about my logic, I commented out my routine line by line. Until finally, my entire ItemUpdating receiver looked like:

[sourcecode language=’c#’]
public override void ItemUpdating(SPItemEventProperties properties) {
// Lots of commented-out lines
base.ItemUpdating(properties);
}
[/sourcecode]

And still, Sandbox is Too Damn Busy.

Then I went to the List Receiver’s Elements.xml file, and commented out the <Receiver…><Type>ItemUpdating</Type>…</Receiver> part. And lo and behold, the Sandbox would suddenly take my calls again.

I then created the simplest test case. One list. One ItemUpdating event receiver which does nothing. One FeatureActivated event receiver that updates a list item. Activation == game over.

Now I understand why updating a ListItem that has an ItemUpdating receiver from a FeatureActivated receiver might be a problem. But, once again, SharePoint has vomited forth one of the least useful error messages possible.

2 Comments

  1. Hi Jason, when you say ‘understand’, are you referring to the architecture of sandbox request handling ? Is there any official docs on this ? There only seems an issue when the update is triggered from Sandboxed code…

  2. Perhaps ‘understand’ is a strong word. I mean something more like, “Having banged my head against various mysterious and sundry limitations of SharePoint, I can imagine that this would probably be yet another gotcha to trap the unwary programmer.”

Leave a Reply