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.