Created by: LawnGnome
When progressWithStatusBarsTTY.Complete is called, the status bars within the progress element are replaced with an empty slice. In the normal case, where the progress really is complete or an error is being handled in an orderly fashion, this is fine.
However, when a disorderly shutdown is occurring due to (say) a signal being received and a context then being cancelled, callers don't necessarily control the order of calls to the progress element. It's entirely possible that progressWithStatusBarsTTY.StatusBarFailf, for example, will be invoked after Complete, at which point attempting to dereference a slice element is an unwise choice.
The interesting part is that we don't really gain any benefit from removing the status bars: the rendering doesn't really change as a result (since in a normal Complete case, the last render still displayed all the status lines), and we maintain safety if there are parallel calls occurring. So, instead, we can just remove the reslice, which actually has the happy effect that (a) src doesn't panic sometimes when you Ctrl-C during execution, and (b) the right output status will actually be displayed to the user.