Description
The existing client already incorporates support for retrials. Should an error occur during execution and it's not a readTimeout, the command undergoes retrying within the _process function. However, there are scenarios where retrying may not be appropriate. Take, for instance, the case where a connection closes during a SetNX operation in Redis. In such instances, we cannot know with absolute certainty if the element was successfully inserted or not. Retrying in this case could lead to misleading outcomes. For instance, if we retry, the key might already exist, causing Redis to return false. This could potentially mislead consumers into believing that the keys weren't present before executing the command.
Expected Behavior
To enhance reliability, consider making the SetNX call idempotent. This ensures that even if it's retried, the outcome remains consistent. If achieving idempotence isn't feasible, it's crucial to signal an error when we cannot ascertain the behavior of SetNX with absolute certainty. This approach fosters clarity and reliability in handling potential retries, safeguarding against ambiguous or misleading outcomes.
Current Behavior
In some cases, SetNX returns false even when no key was previously defined.
Steps to Reproduce
Unfortunately, there is no easy way for me to reproduce the issue :(