Summary
In a parallel catchup run (HistoryPubnetParallelCatchupV2), a single ledger range appears to have been dispatched early, failed/stalled without completing, and then was not retried until every other range had finished — a free worker picked it up hours later and completed it. This added roughly 4h to the total mission runtime.
Suggestion
Improve retry handling so a failed/stalled range is re-queued and picked up promptly rather than waiting for all other ranges to finish — e.g. a visibility timeout / lease reaper on the in-progress set, or explicit failure detection that re-dispatches to any free worker. This would avoid a single straggler serializing at the tail end.
Summary
In a parallel catchup run (
HistoryPubnetParallelCatchupV2), a single ledger range appears to have been dispatched early, failed/stalled without completing, and then was not retried until every other range had finished — a free worker picked it up hours later and completed it. This added roughly 4h to the total mission runtime.Suggestion
Improve retry handling so a failed/stalled range is re-queued and picked up promptly rather than waiting for all other ranges to finish — e.g. a visibility timeout / lease reaper on the in-progress set, or explicit failure detection that re-dispatches to any free worker. This would avoid a single straggler serializing at the tail end.