Reindex progress reports 100% complete as soon as the queue is cleared, regardless of documents indexed

Summary

Reindex progress is computed as total content minus rows remaining in the reindex queue. It never compares against the number of documents that actually reached the index. Any action that empties dist_reindex_journal therefore makes the UI report 100% complete, even when almost nothing was indexed.

Affected version

26.08.03-01 (code path unchanged on main at time of writing)

Steps to reproduce

1. Start a full reindex on an instance with a substantial content set (~90k contentlets).
2. Wait until progress reads roughly 5%.
3. Click Stop Reindex and Make Active (see #37279).
4. Observe the progress panel.

Expected

Progress reflects how much of the index was actually built. Stopping a reindex at 5% should not report completion.

Actual

The bar jumps immediately to 100%, reading Reindex Progress : 90483 / 90483 and Time : n/a, while the panel simultaneously still says "A full reindex is in progress."

Reproduced locally on a ~90k-contentlet dataset; the bar went from ~5% to 100% the instant the queue was cleared.

Code

ESReindexationProcessStatus:

public static int getLastIndexationProgress(int countToIndex) throws DotDataException {
    long left = APILocator.getReindexQueueAPI().recordsInQueue();
    int x = (int) (countToIndex - left);
    return (x < 0) ? 0 : x;
}

public synchronized static int getContentCountToIndex() throws DotDataException {
    dc.setSQL("select count(*) as cc from contentlet_version_info");
    ...
}

recordsInQueue() counts dist_reindex_journal rows with priority < 400. Zero the queue and progress becomes countToIndex - 0 = 100% by construction.

Two secondary problems in the same method:

• countToIndex counts contentlet_version_info rows while the queue is populated from select distinct identifier — different denominators on multilingual/multi-variant content.
• errorCount is sourced from failedRecordCount() (journal rows at priority >= 400), so a queue that was deleted rather than processed also reports 0 failed records.

Impact

This is what makes the failure invisible. In a production incident a reindex that had indexed 30.6% of the corpus reported "100% complete, 0 failed records", and that reading was passed back to us in good faith as evidence the reindex had finished cleanly. Nobody could have known otherwise from the UI.

Suggested fix

• Derive progress from documents actually written to the reindex target, not from queue drain.
• Add a post-switchover assertion comparing the new index document count against count(DISTINCT identifier) from contentlet_version_info, and log loudly (or refuse) on a material shortfall.
• Do not report a completion state while isInFullReindex() is still true.

Related

• #37279 — the control that empties the queue

Related Freshdesk ticket: https://helpdesk.dotcms.com/a/tickets/38957

Start with ESReindexationProcessStatus, getLastIndexationProgress, getContentCountToIndex, and the ReindexQueueAPI recordsInQueue() implementation. Reproduce the queue-clearing scenario described with the ~90k-contentlet dataset and inspect how dist_reindex_journal and the index target are counted. Done means progress and failure reporting reflect indexed documents, denominators align, and the UI does not claim completion while isInFullReindex() remains true.