If a document has been added to and then deleted from the repository since the last backup of the indexes, then the AUTO re-indexing will not re-index anything that was done between the time of the index backup and the document deletion.
Steps to reproduce:
1) Stop Alfresco and make a backup of the indexes
2) Start Alfresco
3) Add a document (1.txt) with the word 'aardvark' in it
4) add a document (2.txt) with the word 'bach' in it
5) delete document 2.txt
6) Add more documents - I think at this point we need to create at least 10 more transactions. I created another 14 documents, just to be sure.
7) stop Alfresco
8) Remove the current indexes
9) Restore the indexes backed up at (1)
10) Make sure index.recovery.mode is set to AUTO
11) restart Alfresco
12) log in
13) Search for aardvark
– document 1.txt is found
– no document is found
When the AbstractReindexComponent checks to see whether or not a deletion transaction is in the index, it considers that if it does not find that TX id in the index then that transaction is correctly indexed. Thus it then re-indexes from that point onwards only.
haveNodesBeenRemovedFromIndex is the cuplrit. However, as I see it, there is no way for us to tell if a deletion transaction is
(a) not in the index because it's been (correctly) deleted, or
(b) not in the index because it's (incorrectly) not been indexed yet.
I think we have to half-ignore deletion transactions for the purpose of checking the health of the indexex.
I.e. if a deletion transaction is still present in the index, that's a failure condition. If it's not, then it's indeterminate, and we have to keep checking other transactions for proof.
Note - this is the opposite problem to what Gab's fix CHK-10113 . I.e. that problem was that a deletion transaction was incorrectly marked as missing from the indexes, causing a re-index. This is a deletion transaction incorrectly marked as present in the indexes, preventing a (required) re-index.
As far as I can see, this is in all versions of Alfresco, up to and including 3.2r