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"

Expected response when keys are empty:

[null, null]
OK

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

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

Properties

retryConnectionError

retryConnectionError: boolean

If true, batch requests will be retried in case of connection errors.

⚠️ Warning: Retrying after a connection error may lead to duplicate executions, since the server might have already received and processed the request before the error occurred.

retryServerError

retryServerError: boolean

If true, failed commands with a retriable error (e.g., TRYAGAIN) will be automatically retried.

⚠️ Warning: Enabling this flag may cause commands targeting the same slot to execute out of order.