You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Spring Boot 3.5 dependency management downgrades Kotlin and coroutines and the app fails at startup #33
Reproduced with the published com.guard-core:spring-boot-guard:1.1.0 in two throwaway Java 17 apps: Maven importing the spring-boot-dependencies 3.5.6 BOM, and Gradle with Spring Boot plugin 3.5.14 plus io.spring.dependency-management. In both, the BOM manages kotlin.version 1.9.25, kotlin-coroutines 1.8.1 and kotlin-serialization 1.6.3 and overrides the versions the adapter and engine were built with (Kotlin 2.4.21, coroutines 1.11.0, serialization 1.11.0).
The result is a startup failure: NoSuchMethodError: kotlinx.coroutines.BuildersKt.runBlockingK$default while creating guardMiddleware. Coroutines 1.11.0 added runBlockingK, which the Kotlin 2.4 compiled classes call, in this adapter and in the guard-core facade. Overriding only coroutines to 1.11.0 gets past startup but every request returns 500 with ClassNotFoundException: kotlin.coroutines.jvm.internal.SpillingKt, because coroutines 1.11.0 needs a Kotlin 2.x stdlib. Overriding both kotlin.version to 2.4.21 and the coroutines version to 1.11.0 works (normal 200, rate limited 429, attack payload 400, security headers present).
The facade compiled against old coroutines is an engine change and out of scope here. What the adapter can do is document the required alignment for Spring Boot 3.5 apps, which I will do in the README and the installation docs.
I reproduced this with the published 1.1.0 in a Maven app (spring-boot-dependencies 3.5.6) and a Gradle app (Boot plugin 3.5.14 with dependency-management). Both resolve kotlin-stdlib 1.9.25, coroutines 1.8.1 and serialization 1.6.3, and both fail at startup with NoSuchMethodError: kotlinx.coroutines.BuildersKt.runBlockingK$default, because coroutines 1.11.0 added runBlockingK and the adapter and the guard-core facade call it. The workaround is to align kotlin.version to 2.4.21 and the coroutines version to 1.11.0, which I documented in #34. The root cause is in the engine, so the fix comes with the 4.5.0 engine release; this issue stays open until then.
Activity
rennf93 commentedon Oct 17, 2026
I reproduced this with the published 1.1.0 in a Maven app (spring-boot-dependencies 3.5.6) and a Gradle app (Boot plugin 3.5.14 with dependency-management). Both resolve kotlin-stdlib 1.9.25, coroutines 1.8.1 and serialization 1.6.3, and both fail at startup with
NoSuchMethodError: kotlinx.coroutines.BuildersKt.runBlockingK$default, because coroutines 1.11.0 added runBlockingK and the adapter and the guard-core facade call it. The workaround is to align kotlin.version to 2.4.21 and the coroutines version to 1.11.0, which I documented in #34. The root cause is in the engine, so the fix comes with the 4.5.0 engine release; this issue stays open until then.fix(filter): stream responses unbuffered unless a body feature is act…