joewitt commented on PR #11671:
URL: https://github.com/apache/nifi/pull/11671#issuecomment-5648972851
one nit to avoid confusion on the log output
Drop the second “of”. Keep files as the only fraction. Treat events as a
running count, same as the existing finish line (`Finished re-indexing {}
events across {} files`).
**Current**
```
Re-indexed {} of {} Files for Partition [{}] including {} of {} Events
```
That reads as two progress bars. The second is `records indexed so far` over
`maxEventId - minEventIdToReindex`, which is an ID span, not a file or record
total. People will do 8,000/50,000 in their head and think they are 16% done
when **files are already done**.
**Better**
```
Re-indexing partition [{}]: completed {} of {} event files; {} events
indexed so far
```
With the same args: `partitionName`, `filesCompleted`,
`totalFilesToReindex`, `reindexedCount.get()`.
**Why**
- **“X of Y event files”** is the thing that actually advances on a timer
(one file finished, including skip/fail). That is the hung-or-not heartbeat.
- **“N events indexed so far”** is still useful (index is moving), and it
matches the completion log, which already does **not** say `of
{eventsToReindex}`.
- You do **not** lose the ID-range context. That is already on the line two
screens up: last indexed ID vs last written ID, “re-indexing up to the last {}
events.” Repeating it as a denominator is what makes the new line a fake
percent.
If you want one extra crumb without lying, append the IDs, not a fraction:
```
…; {} events indexed so far (target IDs {}–{})
```
`minEventIdToReindex` and `maxEventId` are real bounds. Still not “percent
of events left.”
I would not log `eventsToReindex` in the progress line at all.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
