The search query is denied because it originated from a Coveo quick view

A few months ago I was troubleshooting an issue with a failing Coveo index rebuild. Several times, while reviewing the Sitecore logs, I noticed an error occurring very frequently (~250k times in one log file) after the index rebuild process had started:

WARN  The search query is denied because it originated from a Coveo quick view. For more information, enable DEBUG logging for the 'Coveo.SearchProvider.LinqToCoveoIndex`1[TItem]' class.

I put this error message into Google only to find absolutely nothing. Our search page wasn’t even using quick views, so why was this error showing up in the logs? I enabled DEBUG logging but was not able to find a cause of the error. I contacted Coveo Support.

Wait… What is a Quick View Anyway?

Basically it’s a feature of Coveo that lets you preview a page in the index, quickly. You can read more about it here. Even if you aren’t using quick views on your search page, Coveo still uses and renders them. For example, if you open an indexed item’s properties in the Content Browser in Coveo Cloud, you will see a quick view tab. Upon opening that tab, Coveo generates a preview of your page. It’s much like opening the page manually in a browser, except the page renders much faster in a quick view.

Understanding the Issue

When a Coveo index is rebuilding, Coveo visits the item to fill its quick view. If Coveo is visiting a page where you have a very complex component or module running, that might prompt this error to occur. For example, in my client’s site they have a component named Related Articles, which basically shows a list of other articles that are related to this one. This site happened to have hundreds of thousands of articles, all which needed to be indexed, so the Coveo crawler was hitting these articles and their related articles over and over again.

Solutions

Coveo Support provided an article with a potential solution. Apparently, adding a Request.UserAgent check in complex components on indexed pages is one option. This can be placed on a view, model or sublayout, as the article states, but I also found out that you can add it to your back end code, too; and in my case, that seemed like the best thing to do. In the code that gets the related articles, I put this in at the very beginning of the method:

    if (HttpContext.Current != null && HttpContext.Current.Request != null && HttpContext.Current.Request
        .UserAgent.Contains("Coveo Sitecore Search Provider"))
    {
        return null;
    }

After rebuilding the indexes, the quick view warning was suddenly gone.

Another option Coveo provided was to disable queries from quick views completely. You could add the code in Step 1 of this article to your custom search provider config, but supply a value of false. As the document states,

This setting acts as a master switch. If the setting is set to false, the search queries are never executed in the context of the quick view.

Conclusion

The point is, if you have any complex logic running on a page you know you are indexing, you need to handle that via one of the two above solutions. This could speed up your rebuild time too.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s