Not sure if <#C0B8ZTWE4|spring> or <#C1CFAFJSK|coroutines>: It only fails on certain environments `...

# spring

[Robert]

Not sure if #spring or #coroutines:
It only fails on certain environments

- Kotlin + Depencendices: "1.3.61" - coroutines 1.3.+
- Spring Boot 2.2.4.RELEASE

2020-03-06 12:29:59.485 ERROR 28 --- [boundedElastic-5] reactor.core.scheduler.Schedulers        : Scheduler worker in group main failed with an uncaught exception
java.lang.NoClassDefFoundError: kotlin/coroutines/AbstractCoroutineContextKey
	at java.lang.ClassLoader.defineClass1(Native Method)

[elizarov]

Coroutines 1.3.4 depend on Kotlin stdlib 1.3.70

[Robert]

oh ... that's good news

[elizarov]

Not sure how you’ve ended up with fresh coroutines but with old stdlib, since there’s an explicit dependency. Probably some override in dependency resolution somewhere

[Robert]

Strange thing: it's a docker image that works one some env's but fails on some

[elizarov]

How and when dependencies are fetched? Are they compiled into the image or fetched from the network?

[Robert]

compiled fat spring boot jar

[elizarov]

1. Can you check what versions of dependencies were compiled into the image?
2. Do you have full stack-trace of the exception?

[Robert]

1. you have a good gradle task for that?
2. sure

[elizarov]

You can do ./gradlew dependencies. Grep it for kotlinx-coroutines and kotlin-stdlib versions, please

[Robert]

error.log

error.log

[elizarov]

I’m very surprised that it does not fail consistently. Can it be the case that some instances simply have no load (no relevant requests) and thus do not fail (just yet)?

[Robert]

the working instance has load.
The broken instance doesn't respond to any request.
And strangely is not stop

[elizarov]

What’s the story with dependencies? Can you specify the Gradle snippet with dependencies? Do you use spring-bom there? Do you use kotlinx-coroutines-bom?

[Robert]

gradle dependencies

error.logdeps.log

[Robert]

plugins {
    id("org.springframework.boot") version "2.2.4.RELEASE"
    id("io.spring.dependency-management") version "1.0.9.RELEASE"
    id("org.jetbrains.kotlin.plugin.allopen") version "1.3.61"
    kotlin("jvm") version "1.3.61"
    kotlin("plugin.spring") version "1.3.61"
}

extra["kotlinCoroutinesVersion"] = "1.3.+"
extra["springCloudReleaseTrain"] = "Hoxton.RELEASE"

implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:${property("kotlinCoroutinesVersion")}")
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-reactor")

mavenBom("org.springframework.cloud:spring-cloud-dependencies:${property("springCloudReleaseTrain")}")

[elizarov]

I see that you have an explicit dependency onto Kotlin 1.3.61. You should upgrade that to 1.3.70

[Robert]

yes that caused the issue I guess

[Robert]

I'll look into kotlinx-coroutines-bom

[louiscad]

The issue is using a version range: 1.3.+
It's not a good idea to keep on using it, unless you want to keep on having similar issues in the future. Avoiding version ranges is best to know what your code depends on, and ensure your builds are reproducible.

Shameless plug: If you're concerned about knowing your dependencies have updates and applying them quickly, I worked on #gradle-refresh-versions which makes that easy (I'm using it on professional projects).

[Robert]

Removed the version range bumped it to 1.3.4 + 1.3.70.
But I thought Minor Version could be compatible 🙈

[louiscad]

Every release, even bug fixes can break an app that was relying on such behavior.
That's why so many experienced developers recommend reproducible builds, as well as (semi-)automated unit and integration tests, preferrably in CI. 🙂

[Robert]

Good point. I’ll try to integrate your Gradle plugin

[Robert]

Thanks for the quick help guys, this slack is really great 🎉

[sdeleuze]

@elizarov We can’t upgrade to Coroutines 1.3.4 (and 1.3.3) due to this issue : https://www.gitmemory.com/issue/spring-projects/spring-boot/19783/575506102. Any chance you could publish artifacts using Gradle 6 for next release to fix this issue as described by Andy in the link ?

[elizarov]

Ah… Shoot. What can we do about it? We cannot do a general release with Gradle 6, because Android Studio does not support Gradle 6 yet. Is there any known workaround we can apply to Gradle 5 build?

[louiscad]

@elizarov Android Studio supports Gradle 6, and even if it didn't, publishing with Gradle 6 doesn't require consumers of the library to be on Gradle 6, they can be on Gradle 5, 4 or even maven, the pom files are still there, and the marker is only picked up by Gradle 5.3+ and Gradle 6+.

[elizarov]

I think I have a less-intrusive way to fix it. We can remove Gradle metadata from kotlinx-coroutines-bom artifact.

[elizarov]

@sdeleuze I cannot reproduce the issue with the project that is generated by <http://start.spring.io|start.spring.io>. Can you point to some example project that exhibits this problem?

[sdeleuze]

I will asap back at work

[sdeleuze]

Coroutines 1.3.5 which does not provide Gradle metadata for Coroutines BOM seems to work fine based on our tests.

[elizarov]

Glad to hear that. Thanks for the update.