Spring-cloud-sleuth: Running set of unittests fail on line that should never fail

[martinvisser]

When running our whole suite of unittests in IntelliJ with only two @SpringBootTest classes a number of tests fail with the same sort of stack trace. These are just normal unittests without any application context, but they do use classes from Spring Cloud Gateway. No mocking is done around
Sleuth. Running these failed tests they work just fine. So I guess there's some leftover context?
It's hard to describe and I don't see an easy way to create a reproducible example. However this happens every time since the upgrade to Hoxton.SR3. Reverting to Hoxton.SR2 resolves the problem.

The funny thing is that on line 90 in ReactorSleuth the following comment is attached: should never happen, but don't break.

Running through maven there's no issue, which apparently disables assertions.

java.lang.AssertionError
    at org.springframework.cloud.sleuth.instrument.reactor.ReactorSleuth.lambda$scopePassingSpanOperator$0(ReactorSleuth.java:90)
    at reactor.core.publisher.FluxLift.subscribeOrReturn(FluxLift.java:42)
    at reactor.core.publisher.Flux.subscribe(Flux.java:8172)
    at reactor.test.DefaultStepVerifierBuilder$DefaultStepVerifier.toVerifierAndSubscribe(DefaultStepVerifierBuilder.java:867)
    at reactor.test.DefaultStepVerifierBuilder$DefaultStepVerifier.verify(DefaultStepVerifierBuilder.java:823)
    at reactor.test.DefaultStepVerifierBuilder$DefaultStepVerifier.verify(DefaultStepVerifierBuilder.java:815)
    at reactor.test.DefaultStepVerifierBuilder.verifyComplete(DefaultStepVerifierBuilder.java:682)
    at our.TestCase()
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:686)
    ...
    at org.junit.platform.launcher.core.DefaultLauncher.withInterceptedStreams(DefaultLauncher.java:226)
    at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:199)
    at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:132)
    at com.intellij.junit5.JUnit5IdeaTestRunner.startRunnerWithArgs(JUnit5IdeaTestRunner.java:69)
    at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
    at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:230)
    at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:58)

[marcingrzejszczak]

When we're running a build we're reformatting the code to follow our standards. Most likely that's the reason for the "like mismatch"?

[breucode]

For me, reverting to Hoxton.SR2 did not help.

[vvalencia-cl]

For me, reverting to Hoxton.SR2 did not help.

In my case, reverting to Hoxton.SR2 did work.

The tests that fail with Hoxton.SR3 are the ones that doesn't involve any spring code at all, but uses reactive classes (unit tests with mock objects).

In my project, we are using Kotlin 1.3.70, JDK 11.0.6, Spring Boot 2.2.5

[breucode]

As a workaround, you can add spring.sleuth.reactor.enabled: false to your application-{xyz}.yaml ({xyz} being the profile you are using for spring tests).

Credit goes to @gindex

[csh0711]

Same problem here after updating from Hoxton.SR2 to SR3.
Setup: Spring Boot 2.2.6, Hoxton.SR3, Kotlin 1.3.71, JDK 11.0.2

Caused by: java.lang.AssertionError
    at org.springframework.cloud.sleuth.instrument.reactor.ReactorSleuth.lambda$scopePassingSpanOperator$0(ReactorSleuth.java:90)
    at reactor.core.publisher.MonoLift.subscribeOrReturn(MonoLift.java:41)
    at reactor.core.publisher.Mono.subscribe(Mono.java:4195)
    at reactor.core.publisher.Mono.block(Mono.java:1665)
    at de.xxx.yyy.gateway.session.usecases.AbstractSimpleHttpPostSessionEventHandler.handle(SessionEventHandler.kt:45)

Oddly the problem only occurs when running the tests in IntelliJ. _mvn clean test_ still runs.
When disabling Sleuth as mentioned above in the _application-test.yml_ it works.

[martinvisser]

By default assertions are enabled in IntelliJ and not during maven build.
And indeed, disabling assertions makes the tests work.
So as a workaround, removing -ea helps.

On Fri, Mar 27, 2020, 11:51 Christian Schwörer [e-mail]
wrote:

Same problem here after updating from Hoxton.SR2 to SR3.
Setup: Spring Boot 2.2.6, Hoxton.SR3, Kotlin 1.3.70, JDK 11.0.2

Oddly the problem only occurs when running the tests in IntelliJ. mvn
clean test still runs.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/spring-cloud/spring-cloud-sleuth/issues/1583#issuecomment-604935816,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAYF7PES3N42FKM2HR2YSUDRJSAL3ANCNFSM4LEZSUAA
.

[martinvisser]

Just to confirm, it still happens with Hoxton.SR4. Nothing in the release notes mentioned it would be solved, so I'm not surprised ;)

[marcingrzejszczak]

Hey @martinvisser can you create a sample that I can use to test this?

[martinvisser]

@marcingrzejszczak I would love to, but as I said it's hard to describe and I don't see an easy way to create a reproducible example.
I think what happened was that a @SpringBootTest ran and after that a non-@SpringBootTest used some part of the same code within the same JVM, with -ea on.
I'll try to come up with an example, but I can't see if and when.

[marcingrzejszczak]

OK so let's close this issue until then. Once we have something to work on then we will come back to this.

[Guchman]

Same issue after updating to SB 2.3 and kafka 2.5 deps. Don't know how to reproduce and what is the reason

[Happy-Neko]

Same issue with Hoxton.SR6.
Tests work fine locally in IDE and gradle but break on CI server.

[mikhailsoparin]

Same issue with the tests failing on CI server. After some manipulations they started failing locally as well, I guess depends on the order of the test execution..