The problem/use-case that the feature addresses

cluster meet is asynchronous. It synchronously returns OK to caller, and attempts to handshake with the target node asynchronously.

If for whatever reason, the handshake attempt doesn't succeed within a timeout, Redis drops the attempt and stops trying.

There are couple issues with this behaviour:

• It's not robust. If the timeout was due to a transient issue, e.g. a network partition, Redis cannot auto-heal after the issue is mitigated. Callers would need to call cluster meet again to re-initiate the meeting.
• It's not observable. The target node will just simply disappear from the cluster nodes output. As a novice Redis user, it's not obvious if Redis has tried and failed, or it simply lost the cluster meet request due to crash/restart or something. It requires in-depth Redis knowledge to distinguish between the two(by looking at logs).
• It's counter-intuitive. As a person, in our daily life, if we ask person A to meet another person B, and person A says OK. We would expect A to either successfully meet B, or somehow tell us if they couldn't. We don't expect A to just silently stop trying.

Description of the feature

Add a sticky option to the cluster meet command. E.g.

CLUSTER MEET ip port [cluster_bus_port] [sticky]

When sticky is specified, Redis continues to try handshaking with the target until:

• Either it has succeeded.
• Or explicitly told to forget about the target node via cluster forget.

When sticky is specified, and Redis couldn't successfully meet within a timeout, it indicates this with a handshake_timedout flag in cluster nodes output:

3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 127.0.0.1:7005 handshake_timedout - 0 1385503419023 3 disconnected

Alternatives you've considered

None

Additional information

None