Redis [BUG] Changing volatility of Watched keys does not abort Txn

Changing volatility of Watched keys does not seem to abort the Txn.

Background We are using go-redis and the code more or less looks as follows:

c := redisClient // ClusterClient

// in a retry loop
c.Watch(ctx, func(t *redis.Tx) error {

c.Expire(ctx, "foo", time.Duration(2) * time.Second);  // shouldn't this abort the transaction since the key was modified?

// other ops using t to modify the cache state

// persist the same keys if ops above succeeded
}, []string{"foo", "bar"}...)

Similarly, say we c.Persist on a watched key, would it abort any concurrent transactions watching on the same key?

From the documentation (https://redis.io/docs/manual/transactions/#watchcommandswatch-explained), "we are asking Redis to perform the transaction only if none of the WATCHed keys were modified", I would imagine changing volatility of watched keys would abort the txn.

P.S: I know using redis client object inside the watch is a strange (is it discouraged as well?), but we need to change the expiration on the keys and using txn wouldn't really make sense since the operations are queued. We have created a wrapper around Watch which prevents us from expiration the watched keys outside of it - and we need the retry behavior to be there.

Comment From: oranagra

@mohitreddy1996 in the example you gave, i don't see any transaction being used. here's a test i made:

127.0.0.1:6379> set x x
OK
127.0.0.1:6379> watch x
OK
127.0.0.1:6379> expire x 10000
(integer) 1
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set x y
QUEUED
127.0.0.1:6379(TX)> exec
(nil)
127.0.0.1:6379> get x
"x"

Comment From: mohitreddy1996

Yes, I omitted the actual ops using transaction and simply wrote // other ops using t to modify the cache state to make the example as short as possible..

Thanks for the example @oranagra - I wonder if it's an implementation bug on our end or a bug on go-redis..

But to confirm, changing volatility of watched keys (by a different client or within the watch outside of the scope of a txn of the same client) should abort the txns?

Comment From: oranagra

yes, changing volatility "invalidates" the key and should abort any watched transaction. which version of redis are you using? maybe there was a bug?