In testing library(redis) I mistyped the redis host name in redis_server/3, and when I ran the redis/2 command it simply blocked forever. Problably should throw an exception like ping does:
$ ping: nonexistent
ping: nonexistent: No address associated with hostname
As is, redis_server/3 does not check the server address. Calls to redis/3 and anything that depend on it are retried after 10ms, doubling on each failure up to one minute. It then keeps trying for a day. You can change these defaults using library(setting).
The question is when to retry and when not. Is a DNS failure sufficiently different from a failed server which may also be permanently failed or inaccessible due to routing or firewall issues.
We could of course let redis_server/3 do a DNS check. On the other hand, a rebooting cluster may not always have its DNS right from the start. A possible intermediate could be to print some or all connect failures as warnings.
I think this is the proper solution, it keeps the behavior the same, but the user has a warning. (and if necessary the warnings can be silenced). Thanks for your great work.
By “print”, do you mean writing to stderr, or calling a logger, or something else? On Windows, would you open a warning window?
(I’m not a fan of printing warnings, but it’s fine to provide some kind of callback for handling error situations; or you might want to throw an exception)
Something like onerror(Callback) as an option for redis_server/3? Sounds good.
print means print_message/2. That is designed for printing messages and can easily be linked to OS logging facilities (e.g., library(syslog) realizes sending such messages to Unix syslog).
I think we have something for errors, called exceptions 
There is not much you can repair here. There are just two options: try again or give up and raise an exception. The repair needed is typically outside the reach of the client: fix the server or the network.
I will add a sensible message.
I think this is good; so that the user is informed about what is happening.