Update 2 on the horrid "There may be problems with the work item type definition" error

Well I'm back from an extended vacation / company holiday. Before I left a week or so ago, I was working with a member of the TFS development team on what I have been referring to as the horrid "There may be problems with the work item type definition" error. Search this blog for "horrid" and you'll find a number of posts.

First of all, I'd like to thank the TFS development team for reaching out to us on this error. It's very random and I can't reproduce the error on demand, so I was ambivalent about submitting it through connect. The TFS development team however, reached out and asked if they could help. As it turns out, they could.

What we're finding is the error seems to be related to a user's SQL View being out of sync with the tables, after a work item template change. Example changes we're making are adding/removing states and then adding/removing rules (e.g. REQUIRED) around those states. We've come to this conclusion, as first it only happens to certain users (on a variety of different machines). And second, the most common fix is to remove/add the user. From what development tells me, this act will force a refresh of the user's View.

Anyway, we're not out of the woods yet on this. But I'm really happy with the support MS has been offering us with TFS. Compared with my frustrating customer support experiences with ClearCase, TFS (and Teamprise) support is swimmingly.

Update on the horrid "There may be problems with the work item type definition" error

The issue TFS has with the AD displayName changing is bad. But now that we know what it is, it's not so bad. On the other hand, the horrid "There may be problems with your work item type definition.." error continues to give us fits.

The first time we got it, the error was legitimate, though not descriptive. We had a state named the same as a group. Microsoft is fixing this. Fair enough once we got it figured out. Now we seem to get it when ever we're making a lot of state and transition changes. Throw a few rules (e.g. REQUIRED) and we have real problems.

We got it again on Monday. This time I tabled everything I was working on and dedicated myself to figuring it out. I turned logging on by adjusting the web.config's traceLevel to 4 and traceWriter to true. Be careful with this if you don't have a lot of disk space. It will throw you a lot of information. Even with all that information, nothing good came from the logs except the standard "Microsoft.TeamFoundation.WorkItemTracking.Server.ValidationException: Forcing rollback ---> System.Data.SqlClient.SqlException: Forcing rollback" stack trace. Then I deleted all my local cache (typically your first step), but continued to get the error.

Next, out of curiosity, I tried logging into a new machine with my account. Same issue. I then tried Teamprise and TSWA. Same issue in both. Finally, before quitting my job and moving to Mexico, I tried logging into Teamprise using a different account. Something you can do with Teamprise which is a nice feature. This time it worked!

So why? My local cache was all removed. I tired the same account on multiple machines and still got the error. The permissions between my account and the account that works are the same. As a last resort, I restarted IIS thinking maybe something was cached on the server side. Just to be extra safe, I also removed all my local cache again. Sure enough, that did it. I could once again create work items.

So my hypothesis is, TFS must be doing some server side caching for work items. Or maybe there was something in memory that was not being cleaned up correctly? I'll continue to see if this solution works and post my results.