but not sure how will it play out with coroutines ...

# ktor

[Dias]

but not sure how will it play out with coroutines and stuff

[cy]

both coroutines and ktor http client need re-try facilities but not yet introduced

[cy]

for now you can simply run a coroutine in a loop and await until success

[dave08]

Once I saw a snippit Roman posted a while back (needs adapting for new coroutines):

uspend fun <T> retryIO(
		times: Int = Int.MAX_VALUE,
		initialDelay: Long = 100, // 0.1 second
		maxDelay: Long = 1000,    // 1 second
		factor: Double = 2.0,
		block: suspend () -> T): T
{
	var currentDelay = initialDelay
	repeat(times - 1) {
		try {
			return block()
		} catch (e: IOException) {
			// you can log an error here and/or make a more finer-grained
			// analysis of the cause to see if retry is needed
		}
		delay(currentDelay)
		currentDelay = (currentDelay * factor).toLong().coerceAtMost(maxDelay)
	}
	return block() // last attempt
}

Just for retry though...

[cy]

The disadvantage is that you can't use it with child coroutines

[cy]

since a failing child cause the whole job tree to fail

[cy]

in spite of repeat and catch-block

[cy]

so a coroutineScope { } is required at least in this case

[dave08]

Thanks for the comments, we're currently using it with old coroutines... I new it would need a bit of reworking. But at least for a Ktor client call it could do the trick, unless it's being called from an async block...

This might be better @cy:

suspend fun <T> retryIO(
        times: Int = Int.MAX_VALUE,
        initialDelay: Long = 100, // 0.1 second
        maxDelay: Long = 1000,    // 1 second
        factor: Double = 2.0,
        block: suspend CoroutineScope.() -> T): T  {
    var currentDelay = initialDelay
    repeat(times - 1) {
        try {
            return coroutineScope { block() }
        } catch (e: IOException) {
            // you can log an error here and/or make a more finer-grained
            // analysis of the cause to see if retry is needed
        }
        delay(currentDelay)
        currentDelay = (currentDelay * factor).toLong().coerceAtMost(maxDelay)
    }
    return coroutineScope { block() } // last attempt
}

[dave08]

Truth is, event the original version shouldn't cancel anything with suspend functions running inside the block, since anyways any async run without a CoroutineScope will run on the GlobalScope...? So the changed version just allows to create new coroutines in the new scope inside the block lambda...

[dave08]

Unleass I'm missing something?

[cy]

a acoroutine scope need to be inside of repeat

[dave08]

Corrected the code, but I'm still not sure why...

You mean because if the block() throws an exception other than the one being caught, then the whole scope will be cancelled? So if all exceptions were caught, not just IOException then it would be better? I don't think I understand what you mean 100%...

[cy]

because you can launch a couple of coroutines inside of the block

[cy]

one of them can crash

[dave08]

I see, thanks!