ClassCastException in Lua script result processing returning List [DATAREDIS-711]

[spring-projects-issues]

Mark Paluch opened DATAREDIS-711 and commented

Executing a Lua script returning a List response fails during response processing (e.g. applying map or filter operators) with a ClassCastException because of single element emission instead of emitting a list.

Lettuce emits each element of the returned list as single element but the generic types between RedisScript and the returned Flux do not match:

Code to reproduce:

DefaultRedisScript<List> script = new DefaultRedisScript<>();
script.setResultType(List.class);

Flux<List> flow = template.execute(script,…).map(list -> …);

Additionally, generics do not work well with types accepting generics, it would make sense to be able to write the following code:

DefaultRedisScript<List<Integer>> script = new DefaultRedisScript<>();
script.setResultType(List.class);

Flux<List> flow = template.execute(script,…);

NB: execute requires probably a different name and setResultType should be declared like <S extends T> void setResultType(Class<S> resultType)

---

Affects: 2.0 GA (Kay)

Referenced from: pull request #282

Backported to: 2.0.1 (Kay SR1)

[spring-projects-issues]

Mark Paluch commented

After a few iterations, I'm coming to the conclusion that emitting List<T> instead of T might make the most sense for Lua scripting instead of resolving a List<T> and emitting T.

The most convincing reasons are returning null – skipping these would garble up the response – and in several cases, the response array is required as List. We would also match the existing generic signatures and returning the List as-is would align with the imperative scheme

[Star-ho]

I appreciate your insights on preferring to emit List instead of T for Lua scripting. Your reasoning about handling null values and maintaining consistency with existing generic signatures makes a lot of sense.

However, when working with Kotlin, there are some constraints due to its strict generic type system that differ from Java's flexibility with raw types. Specifically, Kotlin does not support raw types like List without specifying type parameters. This strictness is designed to enhance type safety and prevent potential runtime errors.

The Issue
In Kotlin, if you attempt to use T instead of List, you'll encounter type safety issues because Kotlin requires all generic types to have their type parameters explicitly defined. For example:

kotlin

// This will cause a compilation error in Kotlin
fun getScript(): RedisScript<List> {
    // Implementation
}
``
Kotlin enforces that you specify the type parameter, such as List<Any> or a more specific type like List<String>. Without specifying the type, the compiler cannot ensure type safety, leading to errors.

[mp911de]

Do you think it would make sense to introduce a Kotlin extension? If so, feel free to either file a ticket or submit a pull request directly.