Redis 6.2.1 corrects validation of streams with deleted records
Redis 6.2.1 repairs deep stream-payload validation and permits listener settings to change at runtime. The maintenance release also tightens a query-buffer limit and fixes platform-specific behavior.
A validator can reject a valid structure if its accounting omits data that the structure still contains. Redis 6.2.1 corrects that problem for streams with deleted records. The fix concerns the relationship between the stream's logical contents and the records traversed inside its compact representation. A deleted entry can still matter to the validator's traversal even though it no longer belongs to the live data returned to an application.
The 6.2 release notes date the maintenance release to March 1 and classify its upgrade urgency as low. The tagged 6.2.1 notes identify the stream correction alongside runtime listener configuration and platform fixes. This is the first maintenance update to the newly stable 6.2 line, rather than another broad command release.
I have used Redis since its early releases, and I find these representation-level corrections as relevant as the larger API additions. Redis commands make a data model easy to access, but the implementation still needs to preserve that model through deletion and validation. This patch supplies a specific example of the difference between logical removal and physical traversal.
Deleted records remain part of validation accounting
The stream sanitization fix explains the defect directly. Deep validation of a stream listpack needs to count deleted records as well as live ones. Omitting the deleted records causes the final check of the next pointer to fail. The patch adds a test covering that stream state.
The correction does not describe deleted records becoming visible to readers again. It changes what the validator must count while checking the internal structure. Conflating those two roles would produce the wrong explanation of the bug. Live-record semantics and structural traversal have related but different accounting requirements.
The release's accumulated notes provide context for why the validator exists. Redis 6.2 adds dump-payload sanitization to prevent corrupt input from causing crashes. Full validation has an additional linear-time mode that is disabled by default. A deeper check needs to accept valid internal states as well as reject invalid ones, so its representation rules are part of its correctness.
The new regression test targets a state produced by deletion. That matters because a test built only from newly inserted live entries would not exercise the missing count. The patch's explanation identifies both the omitted class of record and the later pointer check affected by the omission. It gives the test a causal basis rather than merely another sample payload.
Listener settings can change without a restart
The same maintenance release includes the runtime listener configuration change. It permits port, tls-port and bind to change through CONFIG SET. These settings determine where the server listens, so the change affects deployment administration independently of the stream representation fix.
The proposal also introduces a socketFds structure that holds a file-descriptor array and its count. The implementation uses it for TCP, TLS and cluster sockets. That internal change gives the listener-management work a common representation for the sockets it manages. It accompanies the externally visible ability to modify the configuration at runtime.
A runtime configuration change and a durable configuration rewrite remain distinct operations. The accumulated 6.2 notes describe CONFIG REWRITE as atomic and requiring write access to the configuration file's directory. The new ability to change a listener setting does not remove that separate filesystem requirement when a deployment intends to persist configuration through a rewrite.
I regard runtime listener changes as useful only when their operational scope stays explicit. Changing a listening address is a deployment action even though it uses a familiar configuration command. The release makes the action available without making the address selection or persistence decision on the operator's behalf.
A minimum input-buffer limit becomes enforced
Version 6.2.1 also prevents setting client-query-buffer-limit below 1 MB. This is a constraint on configuration values, not an assertion that every client's input consumes exactly that much memory. The distinction matters when a limit appears in a capacity calculation. A validation bound establishes which settings the server accepts.
The release includes several platform-specific corrections as well. It repairs compilation on non-glibc systems when jemalloc is not used, and compilation with jemalloc on ARM64 macOS. FreeBSD receives improved memory consumption and memory-usage tracking. Each entry has a defined platform or build condition, so the patch should not be described as a universal allocator change.
Module users receive a new API for obtaining a client's username and a repair for a crash when CLIENT INFO runs through RM_Call. Another change reuses a shared client for RM_Call. These are separate maintenance items from ordinary network clients changing listener configuration.
The stream correction remains the clearest illustration of the release's role. Its validator must traverse deleted records correctly even though application queries care about live contents. The added test retains that deleted-record state, and the implementation's count now includes the entries needed for the final structural check.