Class CleanupScanUnitProgress
This exists because the node percentage ALONE cannot distinguish a scan that is resuming from one that is stuck, and on a resume it is actively misleading. The percentage is derived from the per-unit scanned counts already persisted, so a run that was interrupted with every node counted reads 100% while a unit is still being re-walked — the resumed reader must fast-forward to its checkpoint before it emits anything, and emits nothing meanwhile. An administrator then sees a full bar and a "dry run in progress" chip and has no way to tell which of the two it is. That was the gap this model closes: the per-unit rows were persisted from the start precisely so the straggler would be VISIBLE rather than inferred from a stalled percentage, and nothing surfaced them.
scanComplete is the honest completion signal and the one the console
must trust over the percentage: it is true only when every unit is SETTLED —
DONE, or FAILED with its walk attempts spent — which is the very condition the
terminal transition itself requires.
inFlightUnits is bounded by the reader count, not by the unit count: it
carries the RUNNING units only, so it stays a handful of rows on a corpus whose
unit total is one per space.
-
Constructor Summary
Constructors -
Method Summary
-
Constructor Details
-
CleanupScanUnitProgress
public CleanupScanUnitProgress()
-