You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I do understand that the stampede protection must be disabled for recursive calls for the same key but for unrelated keys this is at least for me unexpected behavior that is hard to diagnose since the calls may not be immediate and in different services.
Possible Solution
If possible only skip the recursion on same key, not all recursive calls.
Additional context
In the Snippet from the test case below I would expect the second call to not be made but to return the cached value.
function functionToCache() {
echo '<p>Computing value to cache</p>';
sleep(1);
return 'value';
}
$pool->get('key1', function(\Symfony\Contracts\Cache\ItemInterface $item) use ($pool) {
// The first call should actually call the function.
echo '<p>' . $pool->get('key2', 'functionToCache', 0) . '</p>';
// Second call should use the now cached value
echo '<p>' . $pool->get('key2', 'functionToCache', 0) . '</p>';
});
The text was updated successfully, but these errors were encountered:
In my case the problem is basically that a service calling an external endpoint is caching the responses but the requests needs an api token that is fetched and cached when needed in the same cache pool. Since this token is not fetched explicitly it's always nested in a CacheContract::get() call and therefore never saved and refetched for every request.
Symfony version(s) affected: 4.2.2
Description
When using the new CacheContract interface as explained at https://symfony.com/doc/current/components/cache/cache_pools.html#using-the-cache-contracts using the
CacheContract::get()
interface all recursive calls made to the same pool fails to save their value and are recomputed even if it's an unrelated cache key.I do understand that the stampede protection must be disabled for recursive calls for the same key but for unrelated keys this is at least for me unexpected behavior that is hard to diagnose since the calls may not be immediate and in different services.
How to reproduce
I've made a simple test gist that demonstrates the problem at https://gist.github.com/tapetersen/cc72ce3f1aaf689bf1450684e364802f
Possible Solution
If possible only skip the recursion on same key, not all recursive calls.
Additional context
In the Snippet from the test case below I would expect the second call to not be made but to return the cached value.
The text was updated successfully, but these errors were encountered: