Retry Strategy in a client library

[Michaël Catanzariti]

Hi all,

I'm currently working on a Rust client library:

https://github.com/dahomey-technologies/rustis

I just reached the point where I'm working on retry mechanisms in case of network timeouts, disconnections or other errors.

An error could occurs when:

1. A command was sent by the client but never reached the server.
2. A command reached the server but its execution timed out.
3. A command was correctly executed by the server but its result never reached the client back.

The problem is that the client cannot make a clear difference between the 3 cases.

Event if the client detects that the problem occurred when writing the command, it could have reached or could have not reached the server.

Consequently, when implementing a retry mechanism, it could be dangerous to retry all the kinds of commands.

I'm thinking about different options to let the user configure the library retry mechanism:

1. No automatic retry at all
2. Let the user provide, in the initial configuration of the connection, a list of command names which could be resent in case of error
3. Let the user provide, when sending a command, a contextual flag, to automatically resend this particular command execution in case of error.
4. Expose a connection configuration to retry only read-only commands
5. Expose a connection configuration to retry only idempotent commands
6. Expose a connection configuration to retry all the commands

These are my questions:

• Is there a built-in way to know which commands are idempotent ? I found nothing here: https://redis.io/commands/command/
• What are you thoughts about all these retry mechanisms ? Do you think some of them are useless or overkill ? Do you think some other mechanisms are missing ?

Thank you for your help,

Michaël

[Marcelo Zimbres Silva]

On Mon, 12 Dec 2022 at 20:21, Michaël Catanzariti
<michael.c...@gmail.com> wrote:
> Hi all,

<snip>

> I'm thinking about different options to let the user configure the library retry mechanism:
> No automatic retry at all

That would result in users having to implement retry themselves, which
might be annoying.

> Let the user provide, in the initial configuration of the connection, a list of command names which could be resent in case of error

Not flexible enough since specific commands cannot opt-out of the behaviour.

> Let the user provide, when sending a command, a contextual flag, to automatically resend this particular command execution in case of error.

That is the most flexible thing to do IMO.

> Expose a connection configuration to retry only read-only commands
> Expose a connection configuration to retry only idempotent commands
> Expose a connection configuration to retry all the commands

Also not flexible enough.

> These are my questions:

<snip>

> What are you thoughts about all these retry mechanisms ? Do you think some of them are useless or overkill ? Do you think some other mechanisms are missing ?

The approach I use in Aedis [1] is to offer flags per request, see
[2]. It covers all variants you describe above.

By the way, consider contributing to the benchmark of Redis clients
here [3]. The Rust implementation I use is based crate Redis [4].

[1] https://github.com/mzimbres/aedis
[2] https://mzimbres.github.io/aedis/classaedis_1_1resp3_1_1request.html#structaedis_1_1resp3_1_1request_1_1config
[3] https://mzimbres.github.io/aedis/index.html#autotoc_md14
[4] https://github.com/mzimbres/aedis/blob/master/benchmarks/rust/echo_server_over_redis/src/main.rs