Distinguish CacheErrorHandler#handleCachePutError based on trigger context

[auto-jazzjack]

Background
I'm using @Cacheable and @CachePut annotations with Redis to implement caching. To support high availability, the service should return responses even when Redis failures occur.

This is my approach.

@Cacheable(...)
public Something mainLogic(...) {
    // main logic
}

@CachePut(...)
public Something putLogic(...) {
    // main logic
}

public class CustomCacheErrorHandler extends SimpleCacheErrorHandler {
    @Override
    public void handleCacheGetError(RuntimeException e, Cache cache, Object key) {
        // log and record metrics — error is swallowed intentionally
    }
}

---

Problem

Current flow when Redis is unavailable:

HTTP Request
  → Redis GET (failure)
  → handleCacheGetError        ← error swallowed ✅
  → mainLogic() executes       ← works as expected ✅
  → Redis PUT (failure)
  → handleCachePutError        ← error NOT swallowed ❌
  → HTTP Request fails         ← client sees error ❌

Overriding handleCacheGetError alone is insufficient. After mainLogic() succeeds, @Cacheable attempts to write the result back to Redis — and since handleCachePutError is not overridden, that error propagates to the client.
However, simply swallowing all errors in handleCachePutError is also problematic: it would silently suppress errors from @CachePut (ex putLogic()).
The core issue is on that handleCachePutError is invoked in two semantically distinct scenarios.

Idea

Option 1 — Add a reason parameter to distinguish the trigger context

handleCachePutError(
    PutReason reason,          // e.g. CACHEABLE_WRITE_BACK vs CACHE_PUT
    RuntimeException exception,
    Cache cache,
    Object key,
    Object value
);

Option 2 — Introduce a dedicated callback for @Cacheable write-back

handleCachePutErrorWriteBack(
    RuntimeException exception,
    Cache cache,
    Object key,
    Object value
);

It separates the two scenarios in interface level.

[jhoeller]

There is a potential solution on the application side: You could declare @Cacheable(sync=true) which leads to a combined callback operation against the cache provider - and if this fails, handleCacheGetError is sufficient to trigger the method locally without any further put attempt. Since there is no independent put operation in the sync=true case, this was logically tied to the combined get operation which failed and has been handled already.

Could this work for your scenario? Unfortunately, this sync=true effect on error handling is not very obvious, so we certainly need to improve our documentation there.

[auto-jazzjack]

I tested your suggestion of adopting sync=true, but it does not work as expected.

Root cause) cacheErrorHandler is never triggered

• When sync=true is applied, the execution flow enters the isSynchronized() branch, which performs an additional Redis call internally.
• Failure occurring in that layer does not trigger cacheErrorHandler either. So, the request from user side fail also.

public abstract class CacheAspectSupport ... {

    @Nullable
    private Object execute(CacheOperationInvoker invoker, Method method, CacheOperationContexts contexts) {
        if (contexts.isSynchronized()) {
            // Special handling of synchronized invocation — cacheErrorHandler not applied
            return executeSynchronized(invoker, method, contexts);
        }
        // ...
    }
}

[jhoeller]

Just double-checking: Are you on a recent enough Spring Framework version? sync=true error handling has been revised in 6.2.0 (#21590) and 6.2.6 (#34708).

If such a sync=true failure does not trigger the CacheErrorHandler even there, it's worth investigating specifically, also for specific behavior in RedisCacheManager.

[auto-jazzjack]

I did above test within the version 6.1.6 which is staled one than your suggestion. I did the same test after bumping up the version to 6.2.7 and sync=true works in the way you mentioned.

I also checked this document telling that main purpose of sync=true is the mechanism for controlling the concurrency.

As matter of course in almost every case we are not in a Redis failure situation, I do not want to take the following as trade-offs.

1. Firing an extra Redis call to achieve locking mechanism
2. Sacrificing latency waiting for a lock

Could I know whether I can achieve this goal by just setting sleepTime as zero / negative value. To return false in below method.

private boolean isLockingCacheWriter() {
	return !this.sleepTime.isZero() && !this.sleepTime.isNegative();
}

[jhoeller]

@auto-jazzjack thanks for checking, good to hear that the error handling for get(key, valueLoader) works as intended in 6.2.x. That said, you also got a point that there is a specific locking trade-off in RedisCacheManager, making the use of get(key, valueLoader) questionable in low-latency scenarios.

@mp911de any advice for the scenario above? Is it possible to use get(key, valueLoader) on RedisCacheManager without extra locking overhead?

[mp911de]

In our Redis implementation, we do support locking independently of sync usage (Cache.get(Object, Callable<T>). Locking can be controlled on a per-Cache configuration level. For low-latency and failure consideration, get(key, valueLoader) can manifest in two commands (a GET and SET) and either can fail.

[jhoeller]

Thanks for the clarification, @mp911de!

@auto-jazzjack so it should be sufficient to use a RedisCacheWriter.nonLockingRedisCacheWriter setup - which is the default used by RedisCacheManager.create(RedisConnectionFactory). No need to even specify a sleep time then. That said, setting the sleep time to zero should also work, as far as I see.

[auto-jazzjack]

Thanks. Let me test your suggestion in this week.