is there any method for setting retry count? about tuskit

[MMasterson]

Just released 1.4.0 with retry count! Closing this issue.

Let me know if you have anymore questions or suggestions!

[MMasterson]

@Acconut Yes! This adds a retry count parameter to the method, in the form suggested by @MohammadrezaZamanieh.

TUSResumableUpload *upload = [self.tusSession createUploadFromFile:fileUrl retry:3 headers:@{} metadata:@{}];

[MMasterson]

Hey @moonsoo there is no method as of yet, but I can look into the android client to see what is happening and recreate it.

Can you please describe your scenario so I can recreate it?

Thanks!

[moonsoo]

@MMasterson

my scenarios are:

• case 1
  retry upload infinitely when i received network failure.
  (it occurs when i set airplane mode)

• case 2
  retry upload infinitely when i received http response error.
  (it occurs when i set one of tus metadata's value to empty string. for instance key is "event_code" and value is "")

i thought: (if i can set retry count to 5)

• case 1 upload fails when i receive network failure over 5 times.
• case 2 upload fails when i receive response error over 5 times.

thanks for your fast feedback

[Acconut]

Could this be related to #27 as both seem to retry forever?

[moonsoo]

@Acconut
i think this could be related to #27 as a sub issue.
if i can set retry count, endless loop could be disappear. then my issues will be gone.

[MrZeeee]

failure block not called when im getting 405 HTTP status code and TUS running on infinite loop for trying again
TUSResumableUpload.m:(372) Server responded to create file with 405. Trying again

i think TUResumableUpload creatUpload method should have 2 other flags :
1- shouldRetry:Bool
2-retryCount:Int

[Acconut]

@MohammadrezaZamanieh Your problem is not related to the issue described by @moonsoo. The "405 Method Not Allowed" error means that you are using the wrong URL endpoint. Please ensure that you are passing the correct file creation URL to TUSKit. If your problem persist, please open a new ticket.

[MMasterson]

@MohammadrezaZamanieh

I still see value in adding these two flags and I'll bump it in the list of priority.

The proposed changes would deprecate the following method
TUSResumableUpload *upload = [self.tusSession createUploadFromFile:fileUrl headers:@{} metadata:@{}];

And introduce these two as a replacement

TUSResumableUpload *upload = [self.tusSession createUploadFromFile:fileUrl headers:@{} metadata:@{} retry:NO];

NO would only try the upload once
YES would try endlessly

TUSResumableUpload *upload = [self.tusSession createUploadFromFile:fileUrl headers:@{} metadata:@{} retryCount:3];

The upload will only try 3 times before failing out.

Does this sound like it would work best or do you have any suggestions how you'd like to see this introduced?

[Acconut]

@MMasterson You're right, these options are still useful. How do you plan on implementing them? Are the retries attempted immediately after each other or is there a delay between them (or maybe even some exponential backoff mechanism)?

[MMasterson]

@Acconut - Thinking about it more, I believe the API for the android SDK and TUSKit should be similar. Looking at the Android SDK, and correct me if I'm wrong, but if an upload fails it just returns a new upload object, allowing a retry up to whatever parameters the developer sets.

That implementation would update the failure block as such

static TUSUploadFailureBlock failureBlock = ^(TUSResumableUpload* upload, NSError* error){
     // Should we try again?
     [upload resume];

    // Handle the error
    NSLog(@"error: %@", error);
};

[Acconut]

if an upload fails it just returns a new upload

You are mostly right but the tus-java-client doesn't return a new upload. Instead, you have to manually query for a new upload. That's what following line in the example (https://github.com/tus/tus-java-client/#usage) is doing:

TusUploader uploader = client.resumeOrCreateUpload(upload);

[MMasterson]

@Acconut that's where the API differs a bit, but it is still the most equivalent practice. I think its the best approach, I'll begin working on it

[Acconut]

Sure, if you think this approach fits TUSKit better then please go ahead 👍

[MrZeeee]

@MMasterson
i think the new method with "retryCount" will be enough and there is no need to method with "retry:NO" because when the retry is NO that means "retryCount:1" and when "retry:YES" that means infinite retries that can be handled with "retryCount:1000" or something like this
@Acconut
i think it would be better if errors like 405 and other failure http Status codes handle in "Failure Block"

[Acconut]

@MohammadrezaZamanieh i think it would be better if errors like 405 and other failure http Status codes handle in "Failure Block"

It's hard to distinguish between errors which can and cannot be fixed by retrying. When in doubt I would prefer to retry anyways because that's not a big loss if it doesn't work. However, I agree that TUSKit should never end up in an infinite retry loop. I am not sure if that's currently the case but if so, I would like to ask @MMasterson to address this :)

[MMasterson]

@Acconut @MohammadrezaZamanieh

It does end up in a loop, and it's infinite until intervention. The upload can be canceled or stopped, but the process of doing so should be updated.

Addressing it this weekend!

[Acconut]

@MMasterson Thank you, perfect!

[Acconut]

Very nice, @MMasterson! Does this also address issue were TUSKit can end up in an infinite retry loop?

It does end up in a loop, and it's infinite until intervention. The upload can be canceled or stopped, but the process of doing so should be updated.