RedisCoroutinesCommands calls are locked after calling multi()

[fedigiorgio]

Bug Report

When invoke multi method in RedisCoroutinesCommands all commands callings into its actions are being locked.

Current Behavior

  suspend fun test(connection: StatefulRedisConnection<String, String>) {
        val coroutines = connection.coroutines<String, String>()
        coroutines.multi {
            set("myKey1", "myValue1") // The execution flow is locked here.
            set("myKey2", "myValue2")
        }
   }

Expected behavior/code

Enqueue the next commands callings and continue with the execution flow.

Environment

• Lettuce version(s): [6.1.5.RELEASE]
• Redis version: [6.2.3]

[mp911de]

Paging @sokomishalov

[sokomishalov]

@fedigiorgio thanks for the report!
Since coroutines API is built on top of reactive API this hang occurred because the underlying publisher hasn't published any value before exec() execution which is called right after closure execution. So it's a very bad deadlock in this case, unfortunately.
I propose to remove this multi extension only for coroutines API until we figure out how to deal with such transactional cases since this API is still experimental.
An alternative workaround is to change closure's receiver parameter from RedisCoroutinesCommands<K, V> to RedisReactiveCommands<K, V> and let the user decide how to deal with it.

suspend fun test(connection: StatefulRedisConnection<String, String>) {
        val coroutines = connection.coroutines<String, String>()
        coroutines.multi { // it as RedisReactiveCommands<K, V>
            set("myKey1", "myValue1").subsribe() // won't hang up 
            set("myKey2", "myValue2").subscribe() // won't hang up
        }
   }

@mp911de how do you think?

[mp911de]

Instead of removing it, I'd vote to deprecate it with a proper note of why transactions aren't a good fit with an imperative coroutine coding style.

[sokomishalov]

@mp911de sounds reasonable. I've opened #1960