Redis 7.0.2 fixes command metadata that can add network requests

A Redis command can execute correctly while the metadata describing it causes a client to do unnecessary work. Redis 7.0.2 fixes that problem for SET and BITFIELD. They were marked as having movable keys even though their key positions did not require that description. Cluster clients could consequently perform extra round trips to establish information already available from a fixed key position.

The June 12 release notes identify this as a Redis 7.0 regression and classify the update as moderate urgency. The same release fixes a startup crash when Redis cannot read a Linux overcommit setting. Neither change adds a new application command, but both affect whether an existing application can use the server efficiently and reliably.

I value Redis's small command interactions. That makes avoidable network work in the client path significant even when the server-side operation remains simple. Metadata is part of the interface a client uses to decide how to send that operation.

Variable access flags do not imply variable key positions

The command metadata fix explains that SET and BITFIELD acquired a key-extraction function as part of earlier work. The logic deriving movablekeys treated that function as evidence that the command needed movable-key handling. In these cases, the variability concerned flags associated with the key, while the command still had one key at a known position.

Those are different properties. Key position tells a client which argument to use for routing. Access flags describe what the operation may do to that key. A command option can change the latter without changing where the key appears. Inferring positional uncertainty from the existence of a specialized extraction function mixed those responsibilities.

The fix combines computation of the legacy key range and the movable-key flag. Native commands have key specifications that can supply the necessary information. A simple complete range can remain representable through the older positional metadata, while an incomplete or incompatible specification still requires movable-key handling.

This also affects module command metadata. The patch updates the path that publishes module key specifications and includes tests for ranges with gaps. A partial legacy range can describe some keys while movablekeys tells the client that the old representation is insufficient for the complete operation. Removing the flag indiscriminately would conceal that requirement.

The added tests explicitly require SET and BITFIELD not to carry the erroneous flag. Tests for module specifications preserve cases that do need it. That combination verifies the distinction the fix intends to make, rather than merely deleting a flag from two named commands.

The metadata can be inspected directly.

COMMAND INFO SET BITFIELD
COMMAND GETKEYS SET metadata-demo value

The first command exposes the descriptions a client can consume. A second request asks Redis to identify the key in a particular invocation. The patch's point is that a client should not need an additional discovery request for every straightforward fixed-position operation because the general command description is misleading.

A diagnostic failure should not dereference missing text

The startup fix concerns /proc/sys/vm/overcommit_memory. The earlier code returned an error when opening the file failed, but it did not set the error message consumed by the caller. Startup then attempted to print that message and could crash during startup.

This is a failure in reporting the environment, separate from establishing the actual overcommit value. An inaccessible file does not prove that the setting has the value Redis would warn about. The fix makes that path return without reporting the specific failed-check result and initializes error-message pointers to null in callers.

The patch also removes a duplicated warning prefix. That is a small output correction, but the central behavior change is that missing diagnostic input no longer causes the startup crash. The release notes identify the crash as a regression introduced in 7.0.1.

Initializing the pointer also makes its initial state explicit in the system-check runner. That does not turn unreadable operating-system information into a known value. It keeps the error-reporting path from treating an unset output parameter as usable text. The distinction is important in constrained environments where a diagnostic file may be unavailable.

Both fixes preserve distinctions in the interface

The metadata error confused variable access information with variable key location. The startup error confused inability to obtain a value with a diagnostic result containing valid explanatory text. Both caused consequences beyond the code's immediate task, either another network request or failure to start the service.

I regard these as useful patch-release work because they correct the surrounding contracts on which ordinary use depends. The command metadata needs to describe what a client must discover. The system check needs to report only the information it actually obtained. Redis 7.0.2 repairs those paths without requiring application code to adopt a new command or a different data model.