Hi @vladak, i have posted my comments here. posting here just incase if you have missed it.
we are still hitting this issue where indexing fails with "Incremental Index Fails with attempting to add file ‘/repo/folder/file' with date matching deleted document” Error . i'm on 1.14.13.
Note that f7dbff5 ("History based reindex vs. git revert", #4609) is already included in 1.14.13 (it's an ancestor of the 1.14.13 tag), so this build has that fix — but the fault still reproduces. It looks like getDocument(file) returns null → the guard (in isStrictlyNewerThanDocument) hits the return true
Scenario (real example, file .java-version):
Between the last-indexed revision and current HEAD, two commits touch the file and cancel out:
commit A: 17.0 → 11.0 (a revert)
commit B: 11.0 → 17.0 (re-apply)
Net content is unchanged (still 17.0), so:
git diff does not list the file, and git does not rewrite it in the working tree → the file's mtime is unchanged (stale).
But both commits touched it, so history-based collection (FileCollector, via git log-style per-changeset accumulation) does include it in the reindex set.
OpenGrok then removes the existing document and re-adds the file, but since the mtime never changed, the new uid (path + mtime) is identical to the one it just deleted → IndexerFault. The file's mtime equals the
timestamp in the error (20260719132438752), confirming the file on disk was never rewritten.
WARNING: cannot get document for ‘**/**/**/.java-version'
Aug 22, 2026 4:36:41 PM org.opengrok.indexer.index.IndexDatabase update
SEVERE: Failed with unexpected RuntimeException
org.opengrok.indexer.index.IndexDatabase$IndexerFault: attempting to add file ‘/repo/folder/file' with date matching deleted document: 20260719132438752
at org.opengrok.indexer.index.IndexDatabase.processFileHistoryBased(IndexDatabase.java:1721)
at org.opengrok.indexer.index.IndexDatabase.indexDownUsingHistory(IndexDatabase.java:930)
at org.opengrok.indexer.index.IndexDatabase.getIndexDownArgs(IndexDatabase.java:845)
at org.opengrok.indexer.index.IndexDatabase.update(IndexDatabase.java:657)
at org.opengrok.indexer.index.IndexDatabase.lambda$updateAll$5(IndexDatabase.java:346)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
i can provide more logs if needed. this bug is not letting us run incremental index with history turned on.
Hi @vladak, i have posted my comments here. posting here just incase if you have missed it.
we are still hitting this issue where indexing fails with "Incremental Index Fails with attempting to add file ‘/repo/folder/file' with date matching deleted document” Error . i'm on 1.14.13.
Note that f7dbff5 ("History based reindex vs. git revert", #4609) is already included in 1.14.13 (it's an ancestor of the 1.14.13 tag), so this build has that fix — but the fault still reproduces. It looks like getDocument(file) returns null → the guard (in isStrictlyNewerThanDocument) hits the return true
Scenario (real example, file .java-version):
Between the last-indexed revision and current HEAD, two commits touch the file and cancel out:
commit A: 17.0 → 11.0 (a revert)
commit B: 11.0 → 17.0 (re-apply)
Net content is unchanged (still 17.0), so:
git diff does not list the file, and git does not rewrite it in the working tree → the file's mtime is unchanged (stale).
But both commits touched it, so history-based collection (FileCollector, via git log-style per-changeset accumulation) does include it in the reindex set.
OpenGrok then removes the existing document and re-adds the file, but since the mtime never changed, the new uid (path + mtime) is identical to the one it just deleted → IndexerFault. The file's mtime equals the
timestamp in the error (20260719132438752), confirming the file on disk was never rewritten.
i can provide more logs if needed. this bug is not letting us run incremental index with history turned on.