NodeSelection dispatch output gets reused

[mp911de]

Discussed in #1875

^{Originally posted by seeday October 6, 2021}
I'm attempting to broadcast commands to all the replicas in a Redis Cluster deployment, but I'm seeing some weird behavior. Code is below. Redis 6.0.9 and Lettuce 6.1.5.

fun doThing(): CompletableFuture<List<Any?>?> {
    return lettuce.connectAsync().thenComposeAsync {
        it.async().replicas().commands().slowlogGet(1)
    }.thenApply {
        it
    }
}

   
fun doThing2(): CompletableFuture<List<Any?>?> {
    return lettuce.connectAsync().thenComposeAsync {
        it.async().replicas().commands().dispatch(
            CommandType.SLOWLOG,
            NestedMultiOutput(lettuce.codec),
            CommandArgs(lettuce.codec).add("GET").add(1)
        )
    }.thenApply {
        it
    }
}

fun doThing3(): CompletableFuture<List<Any?>?> {
    return lettuce.connectAsync().thenComposeAsync { conn ->
        val futures = conn.async().replicas().asMap().values.map {
            it.dispatch(
                CommandType.SLOWLOG,
                NestedMultiOutput(lettuce.codec),
                CommandArgs(lettuce.codec).add("GET").add(1)
            )
        }
        CompletableFuture.allOf(*futures.toArray { arrayOfNulls<CompletableFuture<*>>(it) })
            .thenApply { futures }
    }.thenApply {
        it.map { it.get() }
    }
}

doThing and doThing3 work just fine, however I feel like doThing2 should also work, and I don't quite understand why. The results from doThing2 return jumbled up, weirdly nested, and out of order, like there's multiple threads fighting over the single NestedMultiOutput. I've tried several ways of synchronizing a NestedMultiOutput, but neither locks nor threadlocals work properly.

While 3 does work, (specifically for custom commands), I'm curious as to what option 1 is doing to synchronize the responses properly, why option 2 is not equivalent to 1, and if it's doing it faster than my mess of CompletableFutures in option 3.

Thanks!

We need to document that dispatch cannot be used in its regular form as the CommandOutput is shared across connections and that messes up the result. We should also throw an exception there and consider a dispatch variant accepting a Supplier.