eZ Find sometimes fails to index as content is published. We need to ensure that indexing succeeds.

What causes indexing to fail?

• Temporary Solr overload, or Solr downtime
• Custom datatypes mapped to wrong solr type (I don't have first hand knowledge on this. I would expect this to always fail.)

How it works:

• Depending on site.ini [SearchSettings] DelayedIndexing, eZSearch::addObject() will be called either during the publish operation (eZContentOperationCollection::registerSearchObject()), or when extension/ezfind/cronjobs/ezfindexcontent.php runs.
• In either case it progresses through eZSolr::addObject(), eZSolrBase::addDocs(), eZSolrBase::postQuery(), to eZSolrBase::sendHTTPRequest() which sends the HTTP request to the Solr server.
• In recent eZ Find, there is eZSolrBase::sendHTTPRequestRetry() which will retry a failed request a number of times, according to solr.ini [SolrBase] ProcessMaxRetries. This is a good improvement, but doesn't exist in eZ Find for eZ Publish 4.4 and older.
• In any case, the result (true or false) is passed all the way down to eZSearch::addObject(), but no further, so it can't be acted upon in eZContentOperationCollection::registerSearchObject() or in ezfindexcontent.php.

How can it be improved?

• eZSearch::addObject() should pass on the return status from eZSolr::addObject().
• In eZContentOperationCollection::registerSearchObject() it should trigger an error message that is visible to the end user: "Content was not indexed". Then the user has the option of trying again by republishing.
• In ezfindexcontent.php, the object reference is removed from the pending actions queue even if indexing failed, meaning that the information about which objects to index is lost. It should be kept in the table until indexing has succeeded.