Valkey 9.0.1 repairs buffer and failover state

Resizing a client's output buffer changes more than the pointer used to append its next reply. Any record of a previous write can still refer to the old allocation. Valkey 9.0.1, released on December 9, fixes that stale-reference path alongside corrections to migration authentication and Sentinel failover. Maintainers assign moderate urgency, asking users to schedule an upgrade without treating it as an emergency.

The buffer correction is specific. Client maintenance can grow or reallocate the output buffer while io_last_written still records the earlier address. The next write encounters an assertion because the recorded data no longer refers to the current buffer. The repair updates that retained pointer when it refers to the allocation being replaced.

I prefer Valkey for Redis semantics, and patch releases like this are relevant to that preference. An application can keep issuing the same commands while the server repairs the internal state which makes their execution reliable. There is no new data model to adopt in order to benefit from this correction.

Resizing must preserve references held elsewhere

The patch allocates the replacement buffer and copies the pending content. Before freeing the old allocation, it checks whether the previous-write record points there and redirects that record to the new buffer. The logical output remains the same, but every retained reference needs to describe its current location.

This is different from losing the reply bytes themselves. The copy can preserve the bytes correctly while a second structure retains an obsolete address. Correct buffer ownership therefore includes both the storage operation and the bookkeeping held by subsequent I/O work. The assertion reported in the patch catches a disagreement between those structures.

The triggering maintenance routine resizes client output buffers, so the repair is relevant even when an application does not alter its own protocol behavior. Memory management can change an allocation underneath a record which another server path expects to reuse. That interaction explains why the fix belongs in the resize path.

Migration uses an internal authentication context

Pull request 2785 changes the source-side migration client to use clientSetUser with an internal null-user context. Previously the code directly marked it authenticated. The helper records authentication state consistently while avoiding an unintended association with the default user.

The regression test disables the default user and configures an administrative user on the source and target. It then performs a slot migration and verifies success on both ends. That makes the ACL configuration part of the tested scenario, instead of assuming that default-user permissions are available to internal migration work.

The consequence is a correction to a supported operation under a restricted default-user policy. An installation does not need to reopen its default user merely to compensate for this internal client-state bug. The implementation must assign the appropriate context to the work the server performs on behalf of the migration.

Sentinel distinguishes an ongoing failover

The Sentinel repair addresses a regression introduced in the major release. Sentinel could issue FAILOVER ABORT while reconfiguring a monitored instance even when it had not established that a failover was ongoing. A dedicated Sentinel user configured with the previously documented ACL could lack permission for that extra command, causing failover to fail.

The correction only sends the abort when Sentinel has detected an ongoing failover. The patch description distinguishes ordinary and manual failover, which retain compatibility with the older ACL, from coordinated failover, which requires the additional permission. It also updates the configuration guidance and tests using dedicated Sentinel users.

That distinction matters for upgrade explanations. A broad instruction to add more permissions would miss the behavioral regression. The patch repairs when the server issues the command and documents where the new coordinated operation needs it. Authorization changes should correspond to an operation actually required by the selected failover path.

An unchanged list should not signal modification

The LTRIM correction conditions key-modification signaling on whether trimming removed any elements. The implementation already calculates how many entries it removes on each side. The patch uses their total to decide whether to signal a modification, while retaining the ordinary reply.

This makes internal notification agree with the operation's effect. A command can complete successfully without changing a value, so completion alone does not establish that the key was modified. Consumers of modification state need the latter fact. The patch preserves that distinction without changing how callers request a list range.

Panic shutdown must release inactive threads

The release also fixes an I/O-thread shutdown deadlock. An inactive thread can hold the mutex involved in its waiting state, preventing cancellation from completing as the main thread waits to join it. The correction unlocks the mutex for inactive threads before cancelling them. Active threads already have the different state noted in the patch.

I regard cleanup-path fixes as part of operational correctness. A panic already indicates a serious failure, but shutdown still needs to terminate its threads instead of waiting indefinitely. Valkey 9.0.1 repairs that path alongside the normal-operation state corrections, giving installations on the new major branch a concrete maintenance update to schedule.