You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :(
The text was updated successfully, but these errors were encountered:
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 aSetNX
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 ofSetNX
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
returnsfalse
even when no key was previously defined.Steps to Reproduce
Unfortunately, there is no easy way for me to reproduce the issue :(
The text was updated successfully, but these errors were encountered: