Hello guys, anyone already try integrate new relic with kotlin coroutines ? I change my scheduleExecutor to coroutines, but the data is not shown at new relic dashboard

Hi all, is it a good idea to pass around instances of

CoroutineScope

? Let's say I have a function that calls

launch

. I could do it like this:

fun doSomething() {
  GlobalScope.launch {
    ...
  }
}

but what if I want the

launch

block to be tied to the outer scope? So if the outer scope is terminated so should the

launch

block. What I tried is

fun doSomething(scope: CoroutineScope) {
  scope.launch {
    ...
  }
}

but it doesn't feel right. Or should I better use

suspend fun doSomething() {
  coroutineScope {
    launch {
      ...
    }
  }
}

but then I create a new scope, right?

It depends on what you want

doSomething

to do: • If you want to wait until it finishes doing its work you write

suspend fun doSomething() = coroutineScope { ... }

• If you want it to return quickly with a side effect of launching new coroutine, you write

fun CoroutineScope.doSometing() = launch { ... }

.

Using coroutine syntax to make orchestration of API calls easier to read/write is something I found useful. I could easily see it be so useful that it should go into kotlinx-coroutines... Here I have blocking calls, but I still find coroutine syntax elegant and simple to reason about. Like this:

private fun <A, B> Iterable<A>.parallelMap(context: CoroutineContext, f: suspend (A) -> B): List<B> = runBlocking {
        map { async(context) { f(it) } }.map { it.await() }
    }

val listOfIds.parallelMap(fooApiPool) { fooApiClient.fetchStuff(it)}

(found at: https://jivimberg.io/blog/2018/05/04/parallel-map-in-kotlin/) But what about orchestrating calls to several sources (clients calls could be made suspendable if this is important), where we for example have three source API:s which we would like to be called in parallel, and then the values are awaited and collected? (I'm trying to get rid of RxJava for some use-cases where I found it to be a burden to maintain/debug). What are good patterns here for expressing the execution flow?

Hi everyone, I’m facing a quite strange problem with spring WebClient + coroutines integration. I have the following method with webclient invocation:

fun doSomething(someBody: Body): Mono<Void> {
  return client
			.patch()
			.uri("/someuri")
			.accept(APPLICATION_JSON_UTF8)
			.contentType(APPLICATION_JSON_UTF8)
			.body(BodyInserters.fromObject(someBody))
			.retrieve()
			.bodyToMono(Void::class.java)
			.onErrorMap {
				BusinessServiceException("CODE", "TITLE").apply {
					httpStatus = HttpStatus.FORBIDDEN
					detail = "some detail"
				}
			}
}

To invoke this method in non-blocking way i do following thing:

try {
  clientBean.doSomething(someBody).awaitFirst()
} catch (e: Exception) {
  throw e
}

What i expect is that in case of exception in webclient call there has to be BusinessServiceException caught in catch block above. And BusinessServiceException fields (code, title, httpStatus, detail) have to be populated with values that i’ve set in onErrorMap method on webclient mono response. What i really have is BusinessServiceException with null fields (code, title, httpStatus, detail) and cause field populated with expected by me BusinessServiceException (with all fields filled the same way as i’ve set them in onErrorMap method). BusinessServiceException class looks like this:

public class BusinessServiceException extends ServiceException {
    public BusinessServiceException(String code, String title) {
        super(code, title);
    }
    public BusinessServiceException(String message, Throwable cause) {
        super(message, cause);
    }
}

I’ve tried to debug all this stuff and it seems like that BusinessServiceException’s constructors called 2 times. First time, as expected, the

public BusinessServiceException(String code, String title)

constructor is called, in onErrorMap() method. Second time, unexpectedly, the

public BusinessServiceException(String message, Throwable cause)

constructor is called, somewhere in

private suspend fun <T> Publisher<T>.awaitOne -> override fun onError(e: Throwable) { cont.resumeWithException(e)}

method, and that call wraps original exception in exception of the same type but with null fields (because of wrong constructor call). I couldn’t find the exact place where this constructor could be called. Interesting thing is if i delete this second constructor

public BusinessServiceException(String message, Throwable cause)

from the BusinessServiceException.class - everything works as expected. I would really appreciate any thoughts on this.

I have watched the "Kotlin Coroutines in Practice" talk by Roman Elizarov and learned about the Actor pattern to confine shared mutable state to a coroutine. In this talk, actors are defined using a function whose parameters are ReceiveChannel (for inputs) or SendChannel (for outputs). Since those actors are defined as functions, how does they relate to classes ? Does anyone has concrete examples of how to structure a program with coroutines-based actors ?

what kind of exception handling is for

future { }

?

Hey, I am working on Spring Coroutines support. WebFlux support (

WebClient

and the functional server API) is currently designed as extensions (https://github.com/spring-projects/spring-fu/tree/master/coroutines/webflux) since the API surface is big and only a small part is IO related. For methods returning

Mono

I am just using

Publisher<T>.awaitSingle()

or

Publisher<T>.awaitFirstOrNull()

, no problem there. For method where I need to create a

Mono

from a Coroutine this is less clear to me. I am currently doing

GlobalScope.mono(Dispatchers.Unconfined) { ... }

since with an extension I don't see how I should use constructs like

fun CoroutineScope.doSometing() = mono { ... }

. How I am supposed to handle that when using extensions? Also I am not really leveraging structured concurrency here, but since I am exposing a Reactive Streams core with Coroutines I am not sure yet if this is an issue or not. Support for Spring Data MongoDB (https://github.com/spring-projects/spring-fu/tree/master/coroutines/data-mongodb) and R2DBC (https://github.com/spring-projects/spring-fu/tree/master/coroutines/data-r2dbc) is based on dedicated Coroutines API since almost all the API is related to IO operation, I have used

Co

prefix like for

CoDatabaseClient

for example (https://github.com/spring-projects/spring-fu/blob/master/coroutines/data-r2dbc/src/main/kotlin/org/springframework/data/r2dbc/function/CoDatabaseClient.kt). Translating

Flux

support depends on https://github.com/Kotlin/kotlinx.coroutines/issues/254 so I have not started this part yet. I also still need to implement interop between Reactor and Coroutines context https://github.com/Kotlin/kotlinx.coroutines/issues/284 This is really the early stage, and I am not yet super familiar with Coroutines, so any feedback welcome.

What does this function really mean? Is it launching a coroutine on each invocation?

And which dispatcher will it use?

It’s too bad delegated properties can’t be

suspend

. It would be great to have a property that is backed by a

Deferred

I still haven't managed to verify that a suspending function is called in tests. I created a minimal project demonstrating the problem on GitHub - https://github.com/curioustechizen/kotlin-coroutines-test-issue If anyone has any ideas please let me know.

@curioustechizen Try this

class LogicTest {
    private lateinit var viewmodel: ViewModel

    private var repo: IRepository = mockk(relaxed = true)

    @BeforeEach
    fun setUp() {
        viewmodel = ViewModel(repo, Dispatchers.Unconfined)

    }

    @Test
    fun `when ViewModel init called then it calls repo init`() {
        viewmodel.init()
        verify { repo.init() }
    }

    @Test
    fun `when ViewModel getName called then it calls repo getName`()  {
        viewmodel.getName {  }
        runBlocking {
            coVerify { repo.getName() }
        }
    }
}

Note that I used MockK for the testing framework, not Mockito, but that should not matter. Update: Using Dispatchers.Unconfined is good enough for these tests. There is a known issues with Mockito verifying coroutines, but that should have been fixed in the latest version.

👋 is it ok if I open a subscription to a broadcastChannel and consume the items inside a coroutine and when I'm not interested on receiving items from the channel I just cancel the coroutine or do i need to explicitly close the channel?

Is a completed

Job

a large object? Should I remove old jobs or should they be cleaned up ASAP?

I'm reading the docs here https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-deferred/ so

isCompleted

means cancelled or completed, `isCancelled`means cancelled, so to find out if it completed sucessfully there is no easier way than checking for

isCompleted && !isCanclled

?

reference on azure functions: https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-concepts

Suspending functions are preferred over async/await - but how do you run two suspending function concurrently?

Hi) I'm a bit confused about coroutines on Android: Example 1:

launch(IO) {
            val result = repoRepository.getAllRepos()
            withContext(Main) {
                textField.text = result
            }
        }

Example 2:

launch(Main) {
            val result = repoRepository.getAllRepos()
            withContext(Main) {
                textField.text = result
            }
        }

Question is why i'm not getting android.os.NetworkOnMainThreadException in second example?

I am not sure if there is more concise way of doing that, maybe without need of wrapping failures into something else, something that uses coroutine exceptions handlers or

select

statement, etc

can I write a function, that could be used both in a coroutine context, and outside of a coroutine context, with a single signature, perhaps using an optional

Continuation

parameter?

@Sam Maybe this works, given a CoroutineScope:

scope.coroutineContext[ContinuationInterceptor]

Hello, tutorials on kotlin describe using suspendCoroutine or suspendCancelableCoroutine as the recommended way to deal with external libraries that provide a callback interface. However, most examples given seem to be for one shot results, e.g. make a network request and wait for the result. What would be the idiomatic way to handle interactions with external libraries that provide a listener interface. e.g. FileObserver on Android where we register to observe changes but we do not know when the callback will be issued. Is using Continuation<T> an acceptable method? E.g. https://gist.github.com/hmgeorge/1e5ee34265d5154e05251c1287843515 . or is using a Channel preferred?

I saw some headline while searching about coroutines on one of the the Jetbrains guy's blogs - and only took in the headline that sounded something like "GlobalScope shouldn't be used" - but I didn't really know what a GlobalScope was, now I see I need to read up on it. can't find the blog anymore - so I mean it probably just meant that it shouldn't be used in a specific circumstance but I didn't read the page more than just glimpse the title

“Is it secret Frodo? Is it SAFE?” So I have this piece of code (first serious coroutine hacking I’ve done) where I have a map associating names with lists of data. The main thread will allow clients to access the lists while a daily background thread will update the data. Main thread is read-only, Background thread is write-only. I think, from an app perspective, that this code is safe even if not predictable. So am I correct?

Hello guys, I was exploring kotlin coroutines source code and I found a lot of unused imports. Is this intentionally? or it would be OK if I submit a PR to remove them?

Hey I have a question:

fun main() = runBlocking {
    try {
        cScope()
    } catch (error: Throwable) {
        println(error)
    }
}

suspend fun cScope() = coroutineScope {
    val def = async { failure() }
    try {
        def.await()
    } catch (error: Throwable) {
        println(error)
    }
}

Why is it only possible to

catch

the error when wrapping

cScope()

and not

def.await()

?

👋 hello guys, im a newbie with coroutines. Im trying to test my ViewModel which simplified looks like the attached code. My issue is that sometimes the tests succeeds but sometimes fails. I can't figure out what am I doing wrong. Could someone help me with that? (the repeat is there to see if it works "all the time")