Additional operator

[eugeneyakub]

Hi!
I haven't found a retry(count) operator... Could u append it ? =)
I think it is widely used in network requests.

[couchdeveloper]

I totally agree with you that some retry mechanism is useful, especially for those kind of tasks that may fail and where there is a chance that a later attempt with the same parameters may succeed (for example network requests, where the returned error indicated that the host is not reachable).

But a retry method isn't suitable for a promise class. A promise starts out "undefined" and then gets completed once and only once with either the computed value or an error. If the promise has been completed with a failure, it can not be reused for another attempt.

Fortunately, there's always a way out! But this would be an extension or a helper function which is not necessarily part of the RXPromise library.

Rather than being a method you can easily define a helper method or a free function to accomplish this task. Let me sketch this idea using some Swift-like pseudo code:

Given is a function that performs an asynchronous task and returns a promise (e.g. your network request):

func doSomethingAsync() -> Promise<MyComputedValue>

Then, you need an asynchronous function whose sole purpose is to wait for a certain duration, possibly dependent on external values (e.g. Reachability) and perhaps dependent on the previous number of failed attempts (in order to implement some sort of exponential increasing delay).

func waitForRetry() -> Promise<Void>

Note: when the "delay" expired, the function completes the returned promise.

Hint: You can finish this function and complete the returned promise via Reachability facility, if this seems suitable.

Now, you can implement a function that performs the given task with a retry mechanism:

func doSomethingWithRetryAsync() -> Promise<MyComputedValue> {
    let promise = Promise<MyComputedValue>

    func retry() {
        doSomethingAsync().then { value in
            // succeeded: we are finished and signal the computed value to the returned promise:
            promise.fulfill(value)
        }
        .onError { error in
            switch error {
            case let err as Error where .Fatal == err:
                // fatal error occurred, do not retry and signal the error to the returned promise:
                promise.reject(error)
            default:
               // We got an error where retrying makes sense later. We first wait, and if this
               // succeeds (it might be cancelled!) we continue with another attempt calling
               // the local function `retry` again:
                waitForRetry().then { value in
                     retry( )
                }.onError ( error in 
                     promise.reject(error)
                }
            }
        }
    }
    retry()

    return promise
}

The above approach has a sever disadvantage, though:

The whole process cannot be (easily) cancelled. You cannot easily call cancel by means of cancelling the returned promise: the actual underlying task will be recreated after a failure and then it will create a new promise. The same is true for the "wait task". This should be cancelable as well.
Only after the underlying task succeeds, it finally completes the returned promise.

You might try to implement this idea in Objective-C and it will be definitely feasible - but I fear also, that the challenge is to get the cancellation mechanism right.

Implementing this cancellation mechanism would be easy if there were a cancellation mechanism like it is implemented in FutureLib. If you can use a Swift solution as a replacement for RXPromise, I would recommend FutureLib, where you implement the "retrial" function as shown below:

func taskWithRetry(cancellationToken ct: CancellationToken) -> Future<String> {
    let promise = Promise<String>()

    func retry() {
        task(2, cancellationToken: ct).map { value in
            promise.fulfill("OK")
        }.onFailure { error in
            switch error {
            case let err as CancellationError where .Cancelled == err: 
                promise.reject(error)
            case let err as Error where .Fatal == err: 
                promise.reject(error)
            default:
                print("wait")
                waitForRetry(cancellationToken: ct).map {
                    print("retry")
                    retry()
                }.onFailure { error in
                    promise.reject(error)
                }
            }
        }
    }

    retry()

    return promise.future!
}

The "wait" function can be implemented like below:

func waitForRetry(cancellationToken ct: CancellationToken) -> Future<Void> {
    let promise = Promise<Void>()
    ...
    // Here, you need to eventually complete the promise. This can be a performed
    // by a timer, or anything else - for example a completion handler of the Reachability
    // facility provided by the OS.

    return promise.future!
}

A small snippet how you would use it:

let cr = CancellationRequest()  // this is likely an ivar.
taskWithRetry(cancellationToken: cr.token).map { value in
    print("Succeeded with \(value)")
}.onFailure { error in
    print("Error: \(error)")
}

May be later, you want to cancel the whole "thing" (whatever is executed currently gets cancelled):

cr.cancel()

[eugeneyakub]

Thank you for such a great explanation!
I think i have a much better understanding now =)

I will use your first example, because my legacy obj-c project does not require any cancellation mechanism at all.

[couchdeveloper]

Your welcome!

Still, you need to carefully decide whether this approach doesn't need to be cancelable. Suppose the following scenario:

Let have a table view with "items". When a user tabs on a cell, a detail view will be displayed and in your viewDidLoad method you call your "retry" method:

[self fetchItemDetailsWithId: itemId].thenOnMain(^id(id result) {
    ...
}, nil)
.then(nil, ^id(NSError* error) {
    ...
});

Now, when this method does not succeed it will take for ever. If the user sees the busy indicator for too long, she tabs the "back" button and the table view appears again. But the request(s) continue to execute and will be retried when it failed - there's nothing that cancelled this process.

Now, imagine the user again tabs on the cell: a new call fetchItemDetailsWithId will be executed and this will add starting new attempts to the existing attempts.

You might imagine what happens when the user performs this "back and force" a couple of times ;)
And what would happen, when those requests finally complete successfully?

Well, it might seem obvious, that it would be better to cancel the method fetchItemDetailsWithId in viewWillDisappear, if you would know how. ;)