Is this bug in Flux.cache(history, ttl)?

问题

The following code

        StepVerifier.withVirtualTime((Supplier<Publisher<?>>) () -> Flux.just(1, 2, 3).cache(2, Duration.ofSeconds(10)))
            .thenAwait(Duration.ofSeconds(5))
            .expectNext(2, 3)
            .verifyComplete();

fails with exception

java.lang.AssertionError: expectation "expectNext(2)" failed (expected value: 2; actual value: 1)

If I change the expected values to

.expectNext(1, 2, 3)

it will pass. So it does not respect the history provided in cache method?

回答1:

Caching and TTL are a bit more tricky to test, because when you cache, what you want to test is what a second Subscriber sees. For the original cached Flux, the cache operator is just pass-through. This first pass is what StepVerifier tested (it performed the first subscription).

In order to fix that, simply extract the Supplier and subscribe immediately inside the supplier:

Supplier<Flux<Integer>> supplier = () -> {
        Flux<Integer> tested = Flux.just(1, 2, 3)
                                   .cache(2, Duration.ofSeconds(10))
                                   .log();
        tested.subscribe();
        return tested;
    };

StepVerifier.withVirtualTime(supplier)
            .thenAwait(Duration.ofSeconds(5))
            .expectNext(2, 3)
            .verifyComplete();

This tests that the history limit of the cache is respected.

The TTL is yet another thing. It is not an expiry on cached items for later replay but rather a condition on whether or not to cache an item, according to the arrival "rythm" of the source. So it is more dependent on the source having delays in its emissions. See the tests in FluxCacheTest and how they use delayElements for that.

来源：https://stackoverflow.com/questions/42747613/is-this-bug-in-flux-cachehistory-ttl