Inactivity Timeout During Rebuild

They’re the most common cause of inactivity timeout. The platform usually bugs when you send an invalid document to the index. It might be a PDF that doesn’t have an assigned user or owner, is locked, fails to open, etc. They’re easy to diagnose , since they display error codes (Error_code), like CORRUPTED_DOCUMENT. The index basically tries to protect itself and the platform from corrupted, potentially dangerous data (a document carrying viruses, for example).

Some permissions might not send, or some documents might hold bad permissions. When a document is pushed into the Sitecore Source, it needs to hold the matching permission. Permissions identified on the item as X but in the Coveo index as Y, although they virtually are the same, don’t have matching names, and therefore won’t be recognized by the Sitecore source. The document will be left with an unknown permission, which prevents its indexing after the push.

If you send an item into the Sitecore Source, but the users/permissions don’t follow, you will run into inactivity timeout because the rebuild will have failed. The rebuild process will have failed because there will be one or more documents without a known user. The next section links you to page that explains you how to solve that problem.

Uploading many items in Sitecore can also slow down the rebuild process, as there’s a maximum number of items and/or security identities that may be pushed each hour. If you want to push many items into the Sitecore source, the rebuild will simply take longer to conclude. However, if you’re using an older version of Coveo for Sitecore, you might run into an inactivity timeout. Improvements have been made to more recent versions, and you’re encouraged to upgrade to the most recent one.

However, cases of interruption related to the number of items are very rare. What’s most likely to cause an interruption is the timer refreshing if the upload process detects change in the number of documents.

The step Waiting for documents to be searchable failed because although documents were pushed correctly, the query couldn’t find them. The reason to this failure is usually that the user executing the query doesn’t have the right to see some indexed documents. Invalid permissions trigger security issues in the rebuilt process, which might cause it to fail.

Look up which documents are broken and either remove them from the platform, or fix their issue.

Most problems related to users, groups and permissions associated to pushed items can be validated directly in the "Content Security" tab in the Cloud Administration Console.

To avoid problems with permissions related to a large number of documents, make sure you’re using the Push API batch process, which compresses items before processing them.

To understand the problem related to a failed query, see if indexed dates on indexed documents were updated during the rebuild. If yes, the rebuild is simply still running.