Can ExecuteAsync() == false be caused by an internal timeout, not just a condition / WATCH failure?

[yaskovdev]

Looking at the transaction flow from the docs:

WATCH {custKey}
HEXISTS {custKey} "UniqueId"
MULTI
HSET {custKey} "UniqueId" {newId}
EXEC

In RedisTransaction, if Monitor.Wait times out while waiting for the HEXISTS response or HSET enqueue confirmation, the transaction is aborted and ExecuteAsync() returns false, the same result as when EXEC fails due to a WATCH conflict.

Is there a way to distinguish an internal timeout from a genuine WATCH conflict when ExecuteAsync() returns false?

My use case: I want to retry immediately on a genuine conflict, but back off on a timeout (since retrying under load makes things worse).

Thanks for the great library!

[mgravell]

Currently: no. We could potentially track this and add it to the interface, but honestly: a timeout is a timeout - there's a chance it would have been caught by a heartbeat and nuked anyway. An argument could be made that this should surface as a TimeoutException, but... in most cases, I think "rework the approach" is preferable; this could be via atomic commands at the server (in this case: HSETNX or HSETEX ... {FNX|FXX}, both of which are available via IDatabaseAsync) or Lua (ScriptEvaluate[Async]).

[yaskovdev]

Thanks for the quick response and the suggestions, we'll look into moving to atomic commands or Lua.