Redis 5.0.3 checks transaction writes after a role change

A server can accept a transaction while it is a primary and become a read-only replica before the client sends EXEC. Redis 5.0.3 adds a check at execution time for that transition. Queuing a write under one server role does not establish permission to execute it after the role changes.

Salvatore Sanfilippo announced the release in a December 12 mailing-list post. The release notes carry a December 11 release heading, while the tagged notes also include December 12 commits. This post uses the public announcement date so its account includes the published release as announced.

I value Redis when command behavior remains understandable through an operational transition. A role change is exactly where an assumption made earlier can stop being true. Checking queued writes against the current role makes the transaction boundary correspond to the state in which those writes would actually run.

EXEC checks the accumulated command flags

The transaction patch adds cmd_flags to the client transaction state. Redis initializes it to zero and combines each queued command flags into it. The resulting value records whether any command in the transaction has the write flag.

At EXEC, Redis checks whether the server is now a read-only replica, whether the client is an ordinary client rather than its replication connection, and whether the transaction contains writes. If those conditions hold, it returns an error and discards the transaction. The check happens before executing the queued commands.

MULTI
SET account:42:status active
EXEC

These commands illustrate the relevant interval. A role or configuration change can occur after queuing SET and before receiving EXEC. Redis must evaluate the transaction under the role that exists at execution, even though it accepted the queued command earlier.

The patch explicitly avoids disconnecting every client with a transaction pending. A transaction containing only valid reads does not need to be rejected just because the server has become a replica. Tracking command flags supplies the information needed to distinguish those cases without inspecting every connection at the moment of the role change.

This is a specific correction to transaction execution. It does not claim that a transaction submitted before a topology change will always succeed. It establishes an appropriate failure when queued writes conflict with the current read-only role, while preserving the possibility of valid read-only work.

An error response should not always panic the process

Another networking patch removes a panic from addReplyErrorLength. The old code treated an error sent to a replica-flagged connection as a replication protocol violation serious enough to terminate the server. The release notes identify problematic cases involving replica-mode connections in MONITOR or SYNC mode.

The patch retains the diagnostic logging but removes the unconditional panic in that branch. This narrows the assumption that every such error response necessarily proves a condition requiring process termination. The networking state of the connection alone was too broad a basis for that decision.

A separate input-buffer repair adds a current-client check before trimming consumed query bytes. The code now requires server.current_client to remain non-null before accessing that cleanup path. Both changes concern what remains valid after command processing, though they correct different assumptions.

Slot repair groups related changes on the owner

The cluster-manager patch changes how redis-cli establishes a slot owner during repair. A helper now starts a transaction on the chosen owner, removes any previous local slot assignment, adds the slot, optionally clears slot status, and bumps the epoch before executing the transaction.

This groups the local operations on that node. It should not be described as one transaction spanning the entire cluster. Other nodes still have their own state and receive their own management commands. The specific improvement is that the owner update no longer consists of independent immediate operations on the same connection.

The implementation also examines individual results inside the EXEC reply. A successful outer reply does not establish that every command inside succeeded. The helper permits the expected already-unassigned error only for the relevant first operation and treats other errors as failures. That distinction preserves useful error checking while allowing the repair sequence to handle an absent local assignment.

I prefer that explicit handling to treating a repair command as a single opaque operation. Slot repair contains several state changes with different acceptable outcomes. The patch records one expected error case without suppressing the rest of the transaction results.

Unsupported bindings can leave a usable listener

The listener patch addresses systems configured with both IPv4 and IPv6 loopback addresses when IPv6 is unavailable. Certain unsupported-protocol or unavailable-address errors now allow the binding loop to continue. Startup still fails if no listening socket exists.

bind 127.0.0.1 ::1

The commit describes this configuration in Debian and notes systems with disabled IPv6, including some container environments. The repair allows a valid IPv4 listener to remain useful when the IPv6 address cannot work. It does not make every socket error ignorable, and it does not authorize listening on an unintended address.

These fixes make Redis 5.0.3 relevant beyond its new data type. Queued transactions now respect the current read-only role, error handling avoids an overbroad panic, and cluster repair groups related owner changes while inspecting their results. Each correction addresses a state that can legitimately differ from the one assumed earlier in processing.