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

VirtualTimeScheduler does not run scheduled tasks since 3.3.3.RELEASE #2060

Closed
elefeint opened this issue Feb 27, 2020 · 2 comments
Closed
Assignees
Labels
area/reactor-test This belongs to the reactor-test module status/has-workaround This has a known workaround described type/bug A general bug
Milestone

Comments

@elefeint
Copy link

Expected Behavior

VirtualTimeScheduler runs scheduled tasks at certain intervals.

Actual Behavior

At version 3.3.3.RELEASE, VirtualTimeScheduler runs the task once and never again, even though virtual time elapsed.

Steps to Reproduce

With io.projectreactor:reactor-test:3.2.15.RELEASE, the following test passes. After updating to 3.3.3.RELEASE, it hangs.

@Test
public void isolateIssue() {
	Scheduler.Worker subscriptionWorker = VirtualTimeScheduler.getOrSet().createWorker();
	List<String> source = Stream.of("first", "second", "third").collect(Collectors.toList());


	StepVerifier.withVirtualTime(() -> {
		EmitterProcessor<String> fluxEmitter = EmitterProcessor.create();

		subscriptionWorker.schedulePeriodically(() -> {
			if (source.size() > 0)
				fluxEmitter.onNext(source.remove(0));
			else
				fluxEmitter.onComplete();
		}, 0, 10, TimeUnit.MILLISECONDS);
		return fluxEmitter;
	})
			.expectNext("first")
			.expectNoEvent(Duration.ofMillis(10))
			.expectNext("second")
			.expectNoEvent(Duration.ofMillis(10))
			.expectNext("third")
			.expectNoEvent(Duration.ofMillis(10))
			.verifyComplete();
}

Possible Solution

No solutions, but I suspect #2017 may have something to do with this.

@simonbasle simonbasle added area/reactor-test This belongs to the reactor-test module type/bug A general bug labels Feb 28, 2020
@simonbasle
Copy link
Member

simonbasle commented Feb 28, 2020

Indeed, this is due to this line in the aforementioned change. Due to this, the VTS you set up yourself and kept a reference to was not the one manipulated by expectNoEvent.

we need to introduce a VirtualTimeScheduler#getOrSet(boolean) variant, and use that one with true parameter` in the above factory method.

@simonbasle simonbasle added the good first issue Ideal for a new contributor, we'll help label Feb 28, 2020
@simonbasle simonbasle added this to the 3.3.4.RELEASE milestone Feb 28, 2020
@simonbasle
Copy link
Member

has-workaround: use the 3 parameter variant of withVirtualTime with VirtualTimeScheduler::get and Long.MAX_VALUE as second and third parameters

@simonbasle simonbasle added status/has-workaround This has a known workaround described and removed good first issue Ideal for a new contributor, we'll help labels Feb 28, 2020
@simonbasle simonbasle self-assigned this Mar 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/reactor-test This belongs to the reactor-test module status/has-workaround This has a known workaround described type/bug A general bug
Projects
None yet
Development

No branches or pull requests

2 participants