Redis transaction API consists of two groups of commands:

• transactions (MULTI, EXEC, DISCARD)
• optimistic locking (WATCH, UNWATCH)

The latter can be (relatively) easily implemented via the existing primitives, while the former requires more attention.

There are a few things to keep in mind:

• "group" transaction commands
• handle intermediate results
• consider having a separate connection for blocking operations (this is a general thing to evaluate, and we can and should deal with it later)

With that in mind, here's the rough idea for a primitive that we could use to represent transactions:

sealed trait RedisTransaction[+Out] {
  def commit: ZIO[RedisExecutor, RedisError, Out]
  // zip operators
} 

object RedisTransaction {
  final case class Single[In, Out](command: RedisCommand[In, Out], in: In) extends RedisTransaction[Out]

  final case class Zip[A, B](left: RedisTransaction[A], right: RedisTransaction[B]) extends RedisTransaction[(A, B)]

  final case class ZipLeft[A, B](left: RedisTransaction[A], right: RedisTransaction[B]) extends RedisTransaction[A]

  final case class ZipRight[A, B](left: RedisTransaction[A], right: RedisTransaction[B]) extends RedisTransaction[B]
}

Note that this API forces user to be explicit about transaction boundaries. Internally, its "interpreter" would take care of all protocol details, e.g., calling commit would build a MULTI ... EXEC block at one point.

@anovakovic01 please take a look and let me know if you have any questions about it. Also, don't take this design as absolute truth - as said, it's just a rough idea.

@mijicd Thanks for the instructions. I think that I've understood the base idea. Draft PR will be sent as soon as I sketch something.

Anyone still working on this?

@anovakovic01 is, he can share the current state, and perhaps you could pair up.

Would be happy to assist where I can!

@barthorre Sorry for waiting for an update this long. I'm still working on this one, should send a draft PR soon. It should introduce a single abstraction that will unify both transactions and the regular commands. When API is defined we'll need to update the executor to be able to process transactions. Help will be needed on that part.