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
The following StepVerifier should work independently of how many elements one consumes in the .thenConsumeWhile(...) step (as long as there's an element in the provided flux that causes the condition passed to .thenConsumeWhile(...) to return false).
int CAPACITY = ...;
int end = ...;
List<Integer> expected = IntStream.range(0, end).boxed().collect(Collectors.toList());
ReplayProcessor<Integer> flux = ReplayProcessor.create(CAPACITY);
for (int i = 0; i < CAPACITY; i++) flux.onNext(i);
StepVerifier.create(flux)
.recordWith(ArrayList::new)
.thenConsumeWhile(i -> i < (end - 1))
.expectRecordedMatches(expected::equals)
.thenCancel()
.verify();
Actual behavior
Everything works fine if the thenConsumeWhile condition causes you to consume fewer elements than are available in the underlying flux, however if you consume exactly the number of elements that are available then the expectRecordedMatches step executes but the verify step blocks forever.
Steps to reproduce
Define CAPACITY above as a constant, e.g. 100, and create a function that takes end as an argument and contains the above StepVerifier sequence, then create two unit tests - one that calls the function like so:
myStepVerifierFunction(CAPACITY - 1); // Record CAPACITY - 1 elements.
And another one that calls it with:
myStepVerifierFunction(CAPACITY); // Record exactly CAPACITY elements.
I've created a GitHub repo that does this - see RecordTest.
In my code, I've added a System.err.println call into the expectRecordedMatches step, so you can see there's no problem with this aspect of things - in both tests the expectRecordedMatches step executes and returns true. But in the test where we record exactly CAPACITY elements the verify blocks forever, and in the one where we record less than CAPACITY elements there's no issue.
I've also added an additional test where I consume CAPACITY elements from the flux but miss out the expectRecordedMatches step. In this case, the verify does not block, so it seems it's a side effect of this expectRecordedMatches step that causes the issue.
Reactor Core version
3.2.5.RELEASE
JVM version (e.g. java -version)
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
The text was updated successfully, but these errors were encountered:
Expected behavior
The following
StepVerifier
should work independently of how many elements one consumes in the.thenConsumeWhile(...)
step (as long as there's an element in the provided flux that causes the condition passed to.thenConsumeWhile(...)
to return false).Actual behavior
Everything works fine if the
thenConsumeWhile
condition causes you to consume fewer elements than are available in the underlying flux, however if you consume exactly the number of elements that are available then theexpectRecordedMatches
step executes but theverify
step blocks forever.Steps to reproduce
Define
CAPACITY
above as a constant, e.g. 100, and create a function that takesend
as an argument and contains the aboveStepVerifier
sequence, then create two unit tests - one that calls the function like so:And another one that calls it with:
I've created a GitHub repo that does this - see
RecordTest
.In my code, I've added a
System.err.println
call into theexpectRecordedMatches
step, so you can see there's no problem with this aspect of things - in both tests theexpectRecordedMatches
step executes and returns true. But in the test where we record exactlyCAPACITY
elements theverify
blocks forever, and in the one where we record less thanCAPACITY
elements there's no issue.I've also added an additional test where I consume
CAPACITY
elements from the flux but miss out theexpectRecordedMatches
step. In this case, theverify
does not block, so it seems it's a side effect of thisexpectRecordedMatches
step that causes the issue.Reactor Core version
3.2.5.RELEASE
JVM version (e.g.
java -version
)The text was updated successfully, but these errors were encountered: