CoroutineExecutor exception when using scope.launch

[malliaridis]

I was trying to make use of the CoroutineExecutor on a multiplatform Compose project and separate the network calls from the dispatch(message) calls.

My code structure inside the executor was planned as follow:

private inner class ExecutorImpl : CoroutineExecutor<Intent, Action, State, Message, Nothing>() {
    override fun executeIntent(intent: Intent, getState: () -> State) {
        when (intent) {
            is Intent.LoadPosts -> loadPosts()
            // ...
        }
    }

    private fun loadPosts() = scope.launch {
        dispatch(Message.PostsLoading)
        // Get a result from network transactions inside of withContext(Dispatchers.Unconfined)
        val result = withContext(Dispatchers.Unconfined) { /* ... */ }

        // Dispatch messages and labels in scope.launch again
        result.onSuccess { dispatch(Message.PostsLoaded(it)) }
    }

The above code throws in one of my projects an error when calling scope.launch. The error is an IllegalStateException with the message Module with the Main dispatcher had failed to initialize. For tests Dispatchers.setMain from kotlinx-coroutines-test module can be used. The same code works on a similar project just fine.

I researched this topic a bit to figure out why it fails and realized that Dispatchers.Main could not been initialized. when printing it in my main function inside of application (Compose) on JVM it says Dispatchers.Main[missing, cause=java.lang.NoClassDefFoundError: android/os/Looper].

According to the main dispatcher documentation and to the release notes of Compose 1.1.1 it looked like I just had to add the following dependency:

runtimeOnly(Deps.JetBrains.KotlinX.Coroutines.swing)

This however didn't solve the problem. I even tried to override things like below:

import com.arkivanov.mvikotlin.core.utils.setMainThreadId
import com.badoo.reaktive.coroutinesinterop.asScheduler
import com.badoo.reaktive.scheduler.overrideSchedulers
import kotlinx.coroutines.Dispatchers

fun main() = application {
    overrideSchedulers(main = Dispatchers.Main::asScheduler) // I am not sure if that overrides things for reaktive or coroutine executors
    setMainThreadId(Thread.currentThread().id) // this suppresses "[MVIKotlin]: Main thread id is undefined, main thread assert is disabled", but looks dirty

    // ...
}

but with no success either.

The problem disappears when I use scope.launch(Dispatchers.Unconfined) {...} instead of scope.launch {...}, but it feels like it is wrong because in the documentation of MVIKotlin it says

The Executor is executed always on the main thread, Messages and Labels must be also dispatched only on the main thread.

It feels like I am missing something and I don't properly understand anymore the way things work.

My question is now, what would be the proper setup / structure for executing network transactions and dispatching messages in a CoroutineExecutor when developing a multiplatform project? And which dispatchers are recommended to use?

[arkivanov]

It seems that the issue you are having is actually not related to MVIKotlin, but rather a general coroutines question. You should definitely use Dispatchers.Main, but as you noticed JVM doesn't have a main dispatcher by default. You are correct, for Compose for Desktop you should add kotlinx-coroutines-swing as a dependency. It will add the main dispatcher for Swing.

The error Module with the Main dispatcher had failed to initialize. suggests that the main dispatcher is not missing, but failed to initialise. It's hard to say why without the full stack trace, but most likely some dependency (maybe transitive) brought the Main dispatcher for Android.

First of all, please double check that you are not using extensions-compose-jetpack from Decompose. For MPP Compose you should be using extensions-compose-jetbrains. If there is an issue, it would be good to provide the full stack trace.

Re: overrideSchedulers
Are you using Reaktive in your project? Having Reaktive as a dependency and using CoroutineExecutor is suspicious. If you use coroutines, you absolutely don't need Reaktive and its overrideSchedulers function. If you do use Reaktive, then consider using ReaktiveExecutor instead.

[malliaridis]

[...] most likely some dependency (maybe transitive) brought the Main dispatcher for Android.

Thanks for your helpful input. The stacktrace below contained some weird behavior from the coroutines libraries:

Caused by: java.lang.NoClassDefFoundError: android/os/Looper
	at kotlinx.coroutines.android.AndroidDispatcherFactory.createDispatcher(HandlerDispatcher.kt:55)
	at kotlinx.coroutines.internal.MainDispatchersKt.tryCreateDispatcher(MainDispatchers.kt:57)
	at kotlinx.coroutines.internal.MainDispatcherLoader.loadMainDispatcher(MainDispatchers.kt:38)
	at kotlinx.coroutines.internal.MainDispatcherLoader.<clinit>(MainDispatchers.kt:22)
	at kotlinx.coroutines.Dispatchers.getMain(Dispatchers.kt:57)
	at com.arkivanov.mvikotlin.extensions.coroutines.CoroutineExecutor.<init>(CoroutineExecutor.kt:23)
	at app.chipmunks.home.store.HomeMainStoreProvider$ExecutorImpl.<init>(HomeMainStoreProvider.kt:28)
	at app.chipmunks.home.store.HomeMainStoreProvider$provide$1$1.invoke(HomeMainStoreProvider.kt:21)
	at app.chipmunks.home.store.HomeMainStoreProvider$provide$1$1.invoke(HomeMainStoreProvider.kt:21)
	at com.arkivanov.mvikotlin.main.store.DefaultStoreFactory.create(DefaultStoreFactory.kt:25)
	at com.arkivanov.mvikotlin.core.store.StoreFactory$DefaultImpls.create$default(StoreFactory.kt:21)
	at app.chipmunks.home.store.HomeMainStoreProvider$provide$1.<init>(HomeMainStoreProvider.kt:17)
	at app.chipmunks.home.store.HomeMainStoreProvider.provide(HomeMainStoreProvider.kt:17)
	at app.chipmunks.home.integration.HomeMainComponent$store$1.invoke(HomeMainComponent.kt:26)
	at app.chipmunks.home.integration.HomeMainComponent$store$1.invoke(HomeMainComponent.kt:25)
	at app.chipmunks.utils.InstanceKeeperExtKt.getStore(InstanceKeeperExt.kt:8)
	at app.chipmunks.home.integration.HomeMainComponent.<init>(HomeMainComponent.kt:67)
	... 104 more
Caused by: java.lang.ClassNotFoundException: android.os.Looper
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:636)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:182)
Caused by: java.lang.NoClassDefFoundError: android/os/Looper

	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
	... 121 more
Caused by: java.lang.ClassNotFoundException: android.os.Looper

I double-checked the dependencies of all my modules and realized that I was using in the UI module

androidx.compose.material:material
androidx.compose.material:material-icons-extended

instead of

org.jetbrains.compose.material:material
org.jetbrains.compose.material:material-icons-extended

in commonMain. This caused the error where the coroutines tried to load an Android class in a JVM target.

About overrideSchedulers, I removed it completely now. You are completely right and I was wondering why I continued using it. I migrated from Reaktive to Coroutines, that's why I had it in the code in the first place (I am also using the Consumer from Reaktive which I should replace probably).

P.S. the documentation contained a lot of useful information about the imports in MVIKotlin, thanks for that too. 😄