Phpredis can get confused by multiple redirections in short order leading to a situation where a command is sent to a given node but not fully consumed.
See #1222 for more context to the problem.
When this happens phpredis will then read old data from the previously sent node and be inconsistent from that point until the connection is reset.
Here is instrumented debugging output to illustrate what is happening:
[1875]: Sending command to: 10.0.0.7:6379 <-- sends command but detects
error and fails to consume
full response from server.
[1876]: Sending command to: 10.0.0.5:6379 <-- Starts redirecting for non error.
[1877]: Sending command to: 10.0.0.5:6379
[1878]: Sending command to: 10.0.0.8:6379
[1879]: Sending command to: 10.0.0.7:6379 <-- reaches 10.0.0.7 again, with the
still unconsumed '1875' reply.
[1879]: Expected '1879' but found '1875' <-- We read wrong data.
I have not tracked down precisely which part of the code is failing (or how) but it's pretty clear what is causing the issue.
I'm opening a new issue since it's related but not really the same problem as was being discussed in #1222.
Phpredis can get confused by multiple redirections in short order leading to a situation where a command is sent to a given node but not fully consumed.
See #1222 for more context to the problem.
When this happens phpredis will then read old data from the previously sent node and be inconsistent from that point until the connection is reset.
Here is instrumented debugging output to illustrate what is happening:
I have not tracked down precisely which part of the code is failing (or how) but it's pretty clear what is causing the issue.
I'm opening a new issue since it's related but not really the same problem as was being discussed in #1222.