do we need to cancel the trimming task in some cases?

such as cluster reset

I think we should cancel on emptyData() and this is mostly a concern for active trimming. e.g. after emptyData(), we don't try to unnecessarily continue trimming. I added a commit to cancel pending tasks, in the follow-up PR, it will also cancel active trim tasks. Do you see some other cases that we need to cancel?

here, the master switches to replica, we should cancel, right?

and clusterDelNode?

I'm not sure if we need to cancel it if we become a replica. e.g. trimming on master was in progress, replica finished it earlier. We trigger the failover. The new master will not propagate TRIMSLOTS as there is no unowned data. Though, the new replica will still have keys to be trimmed. So, I feel like replica should continue trimming. Let me know if you have a better solution in mind.

for clusterDelNode(), do we call this for our own node? Is this the scenario that we are removed from the cluster?

Is there a scenario that the node sees itself in the clusterDelNode() ?

hmm, seems I mixed up canceling the trim and canceling the task?

yeah, we have to cancel the task if other party is deleted. So, looks like a node will never figure out it is deleted from the cluster unless you call CLUSTER RESET.

after second thought, we should cancel trimming task if becoming replica, for active trimming, don't cancel if the trimming is in progress, cancel pending trimming tasks

what is different between pending task and active trimming? Consider this scenario:

e.g. trimming on master was in progress, replica finished it earlier. We trigger the failover. The new master will not propagate TRIMSLOTS as there is no unowned data. Though, the new replica will still have keys to be trimmed.

If we cancel the pending trimming task, replica will never do the clean up.

hmm, maybe after active trimming, something will be clear to me.
please merge