Closed Crystark closed 1 week ago
I could not reproduce this as is. If you'd like us to spend some time investigating, please take the time to provide a complete minimal sample (something that we can unzip or git clone, build, and deploy) that reproduces the problem. Another option is some form of integration test that can be easily added to Spring Framework's test suite).
It would be interesting to try and avoid the scheduling aspect, in order to ensure there are as little moving parts as possible.
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Hi, sorry for my late answer @simonbasle
Thanks for getting back to me.
It seems I have missed in my example the @EnableCaching
annotation. Maybe that's why you couldn't reproduce the issue ? Once added I could successfully make this work in a standalone app.
You'll find a maven project here that reproduces the issue. I didn't remove scheduling due to the lack of time on my end. I hope it's sufficient.
Thanks for the reproducer, @Crystark, this provided good context for deeper analysis. Unfortunately, we cannot support context propagation in the case of sync=true
.
Think of it that way: in order to avoid any double invocation of the service method, it is not your controller which subscribes to the mono it returns. Instead, it is the CaffeineCache
which does (by converting the Mono to a Future, which subscribes to it without passing any context).
Imagine two concurrent calls to the cached service, each with a different contextWrite
. With sync=false
both calls fall through and the actual service method ends up being called twice with both contexts. With sync=true
, it becomes undeterministic which of the two callers would "win" and instead the cache itself invokes the method, effectively passing the cached result to both callers.
Hope this helps.
Yes I understand. Thanks for the investigation
Affects: 6.1.8
Describe the bug
@Cacheable
annotation withsync=true
on a reactor publisher returning method looses the reactive contextTo Reproduce
This code reproduces the issue:
Actual behavior
Code execution prints the following
Expected behavior Code should print
Workaround If I remove the
sync=true
it all works as expected so the issue comes from the use ofsync=true
This was originally a question on stackoverflow.