Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StepVerifier.expectRecordedMatches(...) causes verify to block forever if you consume the capacity of the underlying flux #1529

Closed
george-hawkins opened this issue Feb 15, 2019 · 0 comments
Labels
type/bug A general bug
Milestone

Comments

@george-hawkins
Copy link

george-hawkins commented Feb 15, 2019

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).

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)
@smaldini smaldini added the type/bug A general bug label Mar 1, 2019
pmackowski pushed a commit to pmackowski/reactor-core that referenced this issue Mar 26, 2019
pmackowski pushed a commit to pmackowski/reactor-core that referenced this issue Mar 26, 2019
pmackowski pushed a commit to pmackowski/reactor-core that referenced this issue Mar 26, 2019
pmackowski pushed a commit to pmackowski/reactor-core that referenced this issue Mar 27, 2019
pmackowski pushed a commit to pmackowski/reactor-core that referenced this issue Mar 27, 2019
@simonbasle simonbasle added this to the 3.3.0.RELEASE milestone Mar 27, 2019
@simonbasle simonbasle modified the milestones: 3.3.0.RELEASE, 3.3.0.M1 Apr 15, 2019
OlegDokuka pushed a commit to OlegDokuka/reactor-core that referenced this issue Apr 24, 2019
… signals

Fix has also been tested against test [RecordTest](https://github.com/george-hawkins/publish-cancel-test/blob/master/src/test/java/com/example/RecordTest.java) provided by the issue author.

Everything worked fine if publisher ended with `onComplete` signal.
Without `onComplete` ,  `completeLatch` was never decremented and as a result 
verify step blocked forever.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/bug A general bug
Projects
None yet
Development

No branches or pull requests

3 participants