A modern programming language that makes developers happier.

kotlinlang

<https://kotlinlang.slack.com/archives/C0BJ0GTE2/p1550497039044300>

Hey, can I ask you a question? Is there any particular reason why you preferred `GlobalScope.mono`, for example in the WebClient? Isn’t there the risk that, if one of the `mono` fails, the `GlobalScope` will cancel all the others?

I am not yet a Coroutines guru, but I am not sure other will be cancelled with `GlobalScope`. Could you elaborate? Also see <https://kotlinlang.slack.com/archives/C1CFAFJSK/p1548857935692300?thread_ts=1548856043.691400&amp;cid=C1CFAFJSK>.

It seems that our Reactive error handling will take care of managing the Coroutines created when using Spring API, this part is not using structured concurency on purpose, and I plane to use `Unconfined` dispatcher to be more efficient.

But on user side, that can integrate that in structured concurency in their code like I did in <https://github.com/sdeleuze/spring-boot-coroutines-demo>

But we could indeed maybe check in that demo application how things are going on in case of error or cancelation.

Feel free to fork this project and modify it to show me the problematic use case.

I have published that early to be able to have this kind of feedback :wink:

I’m handling the coroutines part for Vert.x and I was curious to see how Spring was going to integrate them. I’m still quite new to coroutines in general, that’s why I was curious about that decision. But if <@U2E974ELT> says that, then I’m definitely wrong :joy:

I will add integration tests to validate it works as expected for errors or cancellation.

Worry not. `GlobalScope`-launched coroutines will not be cancelled when one of them fails. They are not even referenced by the global scope. However, you indeed to have tests on the cancelation/failure scenarios to make sure nothing leaks and all the open resources are timely  closed.

<@U2E974ELT> Thanks for your feedback. Regular exception handling seems to work fine, I get a 500 error and the exception is logged like with Reactive errors. But I am wondering if I should do something special about `CancellationException`. Currently if I throw a `CancellationException` from a suspendable request handler I get 500 error and the exception logged. That seems consistent with `GlobalScope.mono` documentation which mention "Failure with exception or unsubscribe | `error`".

Is it what Kotlin users should expect or should `CancellationException` be handled as a special case on Spring side ?

On the surface it looks fine. However, we don’t usually log CancellationException in coroutines with a stacktrace, since that is supposed be part of normal, code-initiated cancel. But you might make a different choice in Spring. Please, check what you would see in logs when you handle timeouts via Reactor operators to make sure it is consistent.