The recent content feature is built on the search index, and it is possible sometimes for duplicate items to be created in the search index even though we've done our best to try to prevent it from happening. I've added some notes about it to the document rebuilding the search index. At this point I don't really have any better ideas to prevent that from happening and don't have time to throw at that problem right now.

This has been bugging me so much I've investigated further and found the cause. When a new forum post is saved it is indexed twice because first in EditPost.aspx.cs we do this in the handler:

if((thread.PostId == -1)||(userIsAllowedToUpdateThisPost))

{

thread.Post();

(which in turn leads to this.CreatePost(); which leads to OnContentChanged(e); > indexBuilder.ContentChangedHandler(sender, e); >

newID = DBIndexingQueue.Create(

this.siteId,

this.indexPath,

this.serializedItem,

this.itemKey,

this.removeOnly);

(and we see a row created in table [mp_IndexingQueue]

Then we continue through the handler to this

if(!notifyModeratorOnly)

{

thread.NotificationSent = true;

// produces duplicate indexing CF

thread.UpdatePost();

which leads to a second indexing. Commenting out the last line above prevents the duplication.

I think one of many possible fixes might be to a) remove this section from CreatePost()... (in ForumThread.cs)

if (result)

{

ContentChangedEventArgs e = new ContentChangedEventArgs();

OnContentChanged(e);

}

and b) take this line outside its condition so it always runs  ... (in EditPost.aspx.cs):

thread.UpdatePost();

This should ensure every new post gets indexed, but only once. But it's all quite complicated and I might have got this wrong!

I've just committed changes to the repo that should prevent the contentchanged from firing more than once during a post. Now oncontentchanged fires from the Post() not from CreatePost or UpdatePost.

Whether that will solve the duplicate item issue I don't know.

Thanks for the beer! Glad that solved it.

Cheers,

Joe