Interface ClusterBatchRetryStrategy

Defines a retry strategy for batch requests, allowing control over retries in case of server or connection errors.

This strategy determines whether failed commands should be retried, impacting execution order and potential side effects.

Behavior

• If retryServerError is true, failed commands with a retriable error (e.g., TRYAGAIN) will be retried.
• If retryConnectionError is true, batch requests will be retried on connection failures.

Cautions

• Server Errors: Retrying may cause commands targeting the same slot to be executed out of order.
• Connection Errors: Retrying may lead to duplicate executions, since the server might have already received and processed the request before the error occurred.

Example Scenario

MGET key {key}:1
SET key "value"
Copy

Expected response when keys are empty:

[null, null]
OK
Copy

However, if the slot is migrating, both commands may return an ASK error and be redirected. Upon ASK redirection, a multi-key command may return a TRYAGAIN error (triggering a retry), while the SET command succeeds immediately. This can result in an unintended reordering of commands if the first command is retried after the slot stabilizes:

["value", null]
OK
Copy

Note: Currently, retry strategies are supported only for non-atomic batches.