Avoiding deadlocks within okhttp interceptors/authenticator when using retrofit with coroutines adapter

Hi, I used retrofit+okhttp+rxjava, now migrated to coroutines. These have implicit support and from what I know the coroutine adapter is hardcoded to use okhttp’s thread dispatcher (not the caller context, as it was possible with rxjava; the async boolean parameter)

What happens now is that, there are cases where requests need to be initiated from within okhttp’s interceptors/authenticator; which are ran on okhttp’s threads

From what I gather, that threadpool is limited, therefore calling new request when the thread pool is maxed out, will lead to deadlock

(Just for clarification, the pseudo-codey situation is this)

fun OkhttpAuthenticator.authenticate() {
	...
	synchronized(this) {
		runBlocking { retrofitService.suspendingRefreshTokens() }<--- 
		...
	}
}

What is the recommended solution for this?

Having the auth calls declared as synchronous in retrofit? Drive auth layers via a custom (separate) dispatcher? Make dispatcher smart enought not to hop from okhttp thread to okhttp thread? Is there option to not use okhttp’s threadpools as it was in rxjava?

I know this might be out of retrofit scope, but I believe many implementations in the wild have this issue

[ursusursus]

For the calls which needed be called from within okhttp thread I kept them blocking, i.e. no threading applied, returning plain Call<T>. Then for convenience I wrapped it with this

/** Due to the fact that native retrofit coroutines support
 * runs request on OkHttp thread pool, which is hard limited.
 * Refreshing tokens happens from within a Authenticator,
 * which is already run on OkHttp thread, thus resulting in
 * OkHttp thread requesting to spawn another OkHttp thread,
 * which leads to deadlock.
 * Workaround was either run all such requests synchronously,
 * or, as here, simply run them on IO dispatcher, which is
 * unbounded.*/
private suspend fun <T> Call<T>.suspendExecute(): Response<T> {
    return withContext(dispatcherProvider.io) {
        suspendCancellableCoroutine { continuation ->
            continuation.invokeOnCancellation {
                cancel()
            }

            try {
                val response: Response<T> = execute()
                continuation.resume(response)
            } catch (ex: Exception) {
                continuation.resumeWithException(ex)
            }
        }
    }
}

(btw nazdar)

[ywett02]

I deduced it from seeing the following in logs:

Anyway, I am not any okhttp or threads expert. Maybe I was not looking at the correct place.