This fixes a potential bug that was never observed in practice since what happens is that the asynchronous connect returns ok (to fail later, calling the handler) every time, so a ping is queued, and sent_ping happens to always be populated. Howver technically connect(2) with a non blocking socket may return an error synchronously, so before this fix the code was not correct.
It is not clear if files open in append only mode will automatically fix their offset after a truncate(2) operation. This commit makes sure that we reposition the AOF file descriptor offset at the end of the file after a truncated AOF is loaded and trimmed to the last valid command.
Recently we introduced the ability to load truncated AOFs, but unfortuantely the support was broken since the server, after loading the truncated AOF, continues appending to the file that is corrupted at the end. The problem is fixed only in the next AOF rewrite. This commit fixes the issue by truncating the AOF to the last valid opcode, and aborting if it is not possible to truncate the file correctly.
The code to check the number of voters was never updated to follow the new Sentinel specification, so the number of voters was computed using only the set of Sentinels that provided a vote. This means that there is a changing majority on partitions, even if usually the issue is not triggered because of the configured quorum check (what was broken was the other implicit check that requires anyway half of the known sentinels to agree in order to start a failover).
As discussed in issue #1945.
When aof-load-truncated option was introduced, with a default of "yes", the past behavior of the server to abort with trunncated AOF changed, so we need to explicitly configure the tests to abort with truncated AOF by setting the option to no.
Because of the new ability to start with a truncated AOF, we need to correctly release all the memory on EOF error. Otherwise there is a small leak, that is not really a problem, but causes a false positive in the tests that detect memory leaks.
There are instances such as EC2 where the bind address is private (behind a NAT) and cannot be accessible from WAN. https://groups.google.com/d/msg/redis-db/PVVvjO4nMd0/P3oWC036v3cJ