StackOverflowError in DefaultedRedisConnection.set on 4.1.0 (regression from 4.0.6)

[jpbassinello]

Summary

Upgrading spring-data-redis from 4.0.6 to 4.1.0 (via the Spring Boot 4.0.6 → 4.1.0 BOM bump) causes a StackOverflowError inside DefaultedRedisConnection on RedisConnection.set(...) calls. Reverting to 4.0.6 resolves it immediately with no other code changes.

Environment

• spring-data-redis: 4.1.0 (regression), 4.0.6 (last known-good)
• Spring Boot: 4.1.0
• Redis client: Lettuce (default LettuceConnectionFactory)
• Trigger path: org.springframework.cache.CacheManager (Redis-backed) → RedisCache.put → RedisConnection.set(...), invoked here via a Camel SpringCacheIdempotentRepository write, but any Redis-backed @Cacheable/cache-put should reproduce it

Stack trace (prod, truncated — ~994 identical frames)

java.lang.StackOverflowError: null
	at org.springframework.data.redis.connection.DefaultedRedisConnection.set(DefaultedRedisConnection.java:374)
	at org.springframework.data.redis.connection.DefaultedRedisConnection.set(DefaultedRedisConnection.java:374)
	... (repeats)

What we found comparing bytecode across releases

Decompiling DefaultedRedisConnection, RedisConnection, and RedisStringCommands from the published 4.0.5, 4.0.6, and 4.1.0 jars:

• 4.0.5 and 4.0.6 are byte-for-byte identical for DefaultedRedisConnection and RedisConnection — no regression between those two.
• Going from 4.0.6 → 4.1.0, RedisStringCommands changes:
  • set(byte[], byte[], Expiration, SetOption) / setGet(byte[], byte[], Expiration, SetOption) are replaced by new overloads taking SetCondition instead: set(byte[], byte[], SetCondition, Expiration) / setGet(byte[], byte[], SetCondition, Expiration).
  • New default methods appear: digest, delex, xDelEx, xAckDel, xTrim.
• We were not able to pin down the exact recursive pair from bytecode alone (the published jars ship without debug/line-number tables, so we can't map the stack trace's line 374 to a specific overload). Given the timing, our working theory is that the set/setGet overload swap introduced a default-method cycle in DefaultedRedisConnection — e.g. one overload's default implementation now delegates to the other overload's default implementation, which delegates back — but this needs confirmation against the actual 4.1.0 source.

Impact

In our case this crashed a production financial-services payments pipeline (Redis-backed idempotent-write cache used in an Apache Camel SFTP polling route) — every scheduled poll thread died with this error for ~2.5 hours before we identified the Boot/spring-data-redis version bump as the cause and rolled it back.

Workaround

Pin spring-data-redis back to 4.0.6 while keeping Spring Boot on 4.1.0 (override the BOM-managed version). No other code changes needed to avoid the crash.

Ask

Could someone confirm whether this is a known issue with the set/setGet SetCondition refactor in 4.1.0, and whether a patch release is planned? Happy to provide a minimal reproduction if useful.

[mp911de]

Please provide a minimal yet complete sample that reproduces the problem.
You can share it with us by pushing it to a separate repository on GitHub or by zipping it up and attaching it to this issue.

I wasn't able to reproduce the issue through a simple reproducer:

	@Bean
	RedisCacheManagerBuilderCustomizer builderCustomizer(){
		return it -> it.withCacheConfiguration("my-cache", RedisCacheConfiguration.defaultCacheConfig().entryTtl(Duration.ofMinutes(1)));
	}

	@Bean
	CommandLineRunner runner(RedisCacheManager manager){

		return args -> {
			manager.getCache("my-cache").putIfAbsent("key", "value");
		};
	}

Do you happen to know if there is an observability agent involved, something that might run any bytecode transformations?

[jpbassinello]

Update: this turned out not to be a spring-data-redis regression — sorry for the noise. Root cause was on our end: we're using Redisson's RedissonConnectionFactory/RedissonConnection (via the redisson-spring-data-40 artifact), and that connector predates the set(byte[], byte[], SetCondition, Expiration) overload that spring-data-redis 4.1 introduced. Since RedissonConnection (the "-40" build) doesn't implement that overload, calls to it fall through to DefaultedRedisConnection's default-method dispatch and recurse into themselves — that's the StackOverflowError, not a bug in spring-data-redis itself.

Redisson ships a redisson-spring-data-41 artifact (since 4.6.0) whose RedissonConnection implements the new overload directly. Swapping redisson-spring-data-40 → redisson-spring-data-41 (keeping spring-data-redis at 4.1.0) resolved it for us with no other changes.

Leaving this comment in case anyone else hits the same trace using Redisson — the fix is on the Redisson connector version, not here. Closing/feel free to close on your end unless you want to keep it open as a compatibility note for other client implementers.

[mp911de]

Thanks a lot for letting us know, closing this issue then. Evolution of interfaces with our current design turns out to be rather complicated and there is likely no good path forward as defaulting causes these kinds of recursions without us being able to put a UnsupportedOperationException in place.