i’m having trouble with verification of suspending...

# coroutines

[matt tighe]

i’m having trouble with verification of suspending functions with mockito failing randomly. the tests most often pass, but will occasionally fail and i’m not sure why. for example:

@Test
    fun `Submits app selection if selections can be made`() {
        mainActivityViewModel.submitAppSelection(selectedApp)

        runBlocking {
            verify(mockAppsStartupFsm).submitEvent(AppSelected(selectedApp))
        }
    }

class MainActivityViewModel {
    fun submitAppSelection(app: App) {
        if (!selectionsCanBeMade()) return
        lastSelectedApp = app

        val coroutineScope = CoroutineScope(Dispatchers.Default)
        coroutineScope.launch { appsStartupFsm.submitEvent(AppSelected(app)) }
    }
}

AppsStartupFsm#submitEvent is a suspending function.
Changing the runBlocking scope to be function level doesn’t seem to help. Is there something I’m missing with verification of suspending functions?

[matt tighe]

@groostav is the way you’re solving the issue of parallelism just by using the main dispatcher in both places? if so, that’s kind of out of the question, as that suspension function sometimes does work that cannot be handled on Android’s main thread

[matt tighe]

joining a job would maybe work, but is also kind pointless: the coroutines are meant to be fired and forgotten, but they affect state changes which are then observed

[groostav]

ah theres a lot to get to here lol

[groostav]

yeah so, Firstly you can use the code I wrote below to make it concurrent bug single-threaded.

Then you need to find some way to synchronize on the submitEvent call to ensure its gone off.

As the untaggable Allen Wang suggested, you could return a `Job?`:

fun submitAppSelection(app: App): Job? {
  if (!selectionsCanBeMade()) return null

  return launch { app.submitEvent(AppSelected) }
}

then, in your test, call mainActivity.submit()?.join()

[matt tighe]

okay, i can see how that would work. i don’t love the nullable but i can maybe rearrange logic to avoid it

[matt tighe]

would it be bad practice to just delay for some short amount in the test to ensure that the coroutine is launched?

[groostav]

very much so

[matt tighe]

alright, thanks for your help.

[groostav]

A less brittle (but still bad, and also kind've interesting) solution is launch(CoroutineDispatchers.Unconfined)

[matt tighe]

how would that solve the issue?

[groostav]

unconfined will cause the launch block to start immediatley, and only return back to the caller of launch after the first suspension point

[groostav]

is the way you’re solving the issue of parallelism just by using the main dispatcher in both places?

Exactly, through a great deal of effort I can honeslty say this is the best approach. Start off writing single-threaded concurrent code. Parallelize when you need the performance.

that’s kind of out of the question, as that suspension function sometimes does work that cannot be handled on Android’s main thread

this is really odd. This style of suspend-funs-may-return-fast is in C# but was intentionally made more difficult (ie removed) in kotlinx because of the subtle concurrency bugs it can introduce. Typically we statically know if you will suspend or not, the runtime does not get a say in that.

[groostav]

I wouldnt do any of this, I'll make a gist with what I owould do

[groostav]

but regarding the submitEvent function, is it blocking or is it suspending? Is that an android API call?

[matt tighe]

hmmm. you’re making me rethink my work a bit

[groostav]

hah, sorry! I'm trying to make this simple I promise.

[matt tighe]

submitEvent is technically marked as a suspending function, but it never actually suspends anything. i guess i’ve been using the suspend modifier to also indicate functions that need to happen off the main thread

[matt tighe]

android will throw exceptions if things like network and database io are done on the main thread

[groostav]

returning a Job? is a good quick fix, theres a bunch of places in my code where I've had to do that, particularly when old java is involved. But I think you might be better off doing a withContext and just making submitAppSelection tagged as suspend

[matt tighe]

that could work. i was just trying to have the suspension point start in that class to associate the logic of getting off the main thread at that layer of the architecture

[groostav]

I would do this:

https://gist.github.com/Groostav/5870edde62a40235f6dc8e67c7830437

[matt tighe]

cool, i can dig that approach

[matt tighe]

can you explain a little more what you mean by your comment `// 2. synchronize on the result, only after submitEvent returns (not suspends) will submitAppSelection return.`

[groostav]

so withContext never does anything in parallel, it will return only when the block inside it returns. Thus your function is made synchronous. It suspends, and it does not hold on to the Main thread because the thing that might block (the submitEvent) call is not on the MainThread, its on a worker thread.

[groostav]

alternatively put, if you had

println("before withContext!")
withContext(Dispatchers.Anything){
  println("before submitEvent!")
  submitEvent()
  println("after submitEvent!")
}
println("after withContext!")

you would only ever see the exact sequence

before withContext!
before submitEvent!
after submitEvent!
after withContext!

[groostav]

lastly,

submitEvent is technically marked as a suspending function, but it never actually suspends anything. i guess i’ve been using the suspend modifier to also indicate functions that need to happen off the main thread

I think you should follow that suspend up with a withContext. This is exactly what I do with my database facade.

class SuspendingTable {
  suspend fun get(id: UUID): T   {
    return withContext(<http://Dispatchers.IO|Dispatchers.IO> + Trace){
      backingDb.getBlocking(id)
    }
  }
}

[matt tighe]

so if i decorate (idk if that’s the right terminology) the suspending submitEvent function with withContext(Dispatchers.Default) i can also remove the withContext call from submitAppSelection, correct?