Probably caused by the same code as bug #71 however I'm making a separate bug report as this will be much harder to fix.
Basically, clients of redis-cluster-proxy (r-c-p for short) that need to track the state of the connection to the redis server do not get that information, leading to breakage.
Such as: a client uses AUTH and r-c-p gives them a special set of connections. But, if those connections fail midway - like if the server gets restarted, look into bug report #71 for examples of reproduction - the client does not get this information and is unable to correct its behaviour. As in, the TCP connection between the client and r-c-p shows no action, while the one between r-c-p and redis is clearly being torn down. On subsequent commands, r-c-p reopens (!) the connection to the redis server, but without AUTH and the client gets "-NOAUTH Authorization required", but not all clients are built to handle repeatedly authorizing themselves to the server.
Notice that, from the clients point of view, it performed a successful authorization, issued some commands that were executed successfully, and then out of the blue it starts getting NOAUTH as a response to its commands. This is super-tricky to handle in code. The rational conclusion from the perspective of the client code, assuming usage of redis-6, is that a human administrator changed the ACLs in the middle of the session. As the computer program (especially a library) is unable to cope with such events, the sanest thing to do is fail with massive errors. Which is what clients do, in general it seems. There does not seem to be a rational explanation why this would happen in redis-5 and earlier, if the client were talking directly to redis.
Probably caused by the same code as bug #71 however I'm making a separate bug report as this will be much harder to fix.
Basically, clients of redis-cluster-proxy (r-c-p for short) that need to track the state of the connection to the redis server do not get that information, leading to breakage.
Such as: a client uses AUTH and r-c-p gives them a special set of connections. But, if those connections fail midway - like if the server gets restarted, look into bug report #71 for examples of reproduction - the client does not get this information and is unable to correct its behaviour. As in, the TCP connection between the client and r-c-p shows no action, while the one between r-c-p and redis is clearly being torn down. On subsequent commands, r-c-p reopens (!) the connection to the redis server, but without AUTH and the client gets "-NOAUTH Authorization required", but not all clients are built to handle repeatedly authorizing themselves to the server.
Notice that, from the clients point of view, it performed a successful authorization, issued some commands that were executed successfully, and then out of the blue it starts getting NOAUTH as a response to its commands. This is super-tricky to handle in code. The rational conclusion from the perspective of the client code, assuming usage of redis-6, is that a human administrator changed the ACLs in the middle of the session. As the computer program (especially a library) is unable to cope with such events, the sanest thing to do is fail with massive errors. Which is what clients do, in general it seems. There does not seem to be a rational explanation why this would happen in redis-5 and earlier, if the client were talking directly to redis.