Hi all,
We started using the spring cache abstraction in our REST API. The methods we want to cache make an HTTP request to a third-party API using WebClient.
The issue occurs when the @Cacheable method returns a Flux, we can see in the logs that the HTTP request is submitted twice instantly. This does not happen when the method returns a Mono.
I was hoping to gain some understanding as to why this double call occurs and how to avoid this from happening? Thanks for your input.
Using spring-boot 3.2.3, spring-webflux. Here is a small project showing the issue: https://github.com/dor3no/cacheable-double-request
Comment From: simonbasle
I was able to reproduce this and will have a look at how we can improve puts in reactive caching support.
Comment From: dor3no
@snicoll @simonbasle Thank you both for having a look.
Comment From: simonbasle
The fix is done and additionally handles cases where the initial subscriber to the cacheable Flux does small incremental request(s) or cancels. For instance, if you use myCacheableFlux().take(3) the caching will not trigger an unbounded request to entirely consume the original Flux, but rather just stick to the 3 requested elements.
Comment From: simonbasle
thinking about it a bit more, I'm not satisfied with the above change. from a user perspective, this makes the caching a bit too nondeterministic... the number of elements cached would now actually depend not only on the operators used in the Flux-caching method but also on the operators / request pattern from the first actual subscription to said Flux.
with the example previously used (myCacheableFlux().take(3)), if a second call to the myCacheableFlux method is performed later like myCacheableFlux().collectList(), it will only reflect 3 elements even though the original Flux might have been capable of emitting many more.
I'll revert my change to get back to the previous behavior (exhausting the original Flux in a parallel subscription), with a different approach at fixing the issue.