Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

spring-projects-issues opened this issue Oct 4, 2017 · 1 comment
in: core in: lettuce type: bug


Copy link

spring-projects-issues commented Oct 4, 2017

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<>();

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<>();

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)

Copy link

spring-projects-issues commented Oct 5, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core in: lettuce type: bug
None yet

No branches or pull requests

2 participants