In pr #1791 "improve scrub status reporting resolution." the additional scrub end states of 'halted' (interrupted), 'conn-reset' (connection reset by peer), and 'cancelled' (aborted) were introduced. Although the indicated pr addressed the mis-reporting of 'halted' (interrupted) as a running state it did not extend knowledge of the referenced additional states to the scheduled scrub manager. So although subsequent manual scrubs could be performed 'on top' of a now correctly identified 'halted' scrub a scheduled scrub was still not able to recognise this new scrub state as terminal: only 'error' and 'finished' were recognised as terminal (non running).

So from a scheduled scrub perspective any scrub performed manually (via Web-UI) or via a prior schedule (untested) that was then halted, cancelled, or resulted in a connection reset would block all future scheduled jobs on that same pool as although manual scrub awareness was extended to encompass the 'halted', 'conn-reset' and 'cancelled' states, the scheduled scrub mechanism was not.

The work around for this state is to enact a Web-UI initiated manual scrub that ends in state finished. There after the existing scheduled scrubs on the same pool would no longer be blocked as they are able to recognise 'finished' as a terminal scan state and initiate a new scrub task as a result. The force option is not required to enact this 'reset'.

Issue Tasks:

• extend scheduled scrub manager's knowledge of the recently added terminal states.
• test existing scheduled scrub tasks ability to recover / re-start post issue fix.

This issue was found while investigating the cause of #1798 but is not believed to be a mutual fix as it does not explain the list type specified in that issue.