Canceling a task by id continues to retry task

[cwalo]

This might be a bit of an edge case, but when a task is cancelled by id (client.cancel(id:)), SchedulerDelegate.onError will continue to schedule the task, causing it to increment errorCount until it reaches the retryCount. As a result, on the next app start, for example, calling client.start() does not resume the canceled upload. The only way to resume the upload is to access client.getStoredUploads and resume them individually. This behavior differs from client.stopAndCancelAll, which causes onError to return early.

In lieu of a pause method, I would expect cancel(id), without removing the cache, to support resuming the stored upload via client.start.

I suspect there might need to be an additional check in onError that checks task.isCanceled or task.didCancel that skips metaData.errorCount += 1 and perhaps immediately calls delegate.uploadFailed(id: metaData.id, error: error, context: metaData.context, client: self)

[donnywals]

I'll look into this, I imagine that we'd want to expand the states that an upload can be in so we can distinguish between actual cancellation and pausing.

In lieu of a pause method, I would expect cancel(id), without removing the cache, to support resuming the stored upload via client.start.

If we add this I would think that the inverse might be requested and that would make sense too. When you intended to actually cancel an upload, then I wonder whether it's expected that the upload would resume in start.

This will require a bit more thinking and exploring to see impact and the best way to move forward. I understand the request and I agree that a lack of pause support makes using cancel a bit weird...

[donnywals]

This one should be fixed by #220