Dragonfly 1.14.2 fixes mutation ordering and script replication

Renaming a key over an existing destination should not terminate a database process. In Dragonfly, that ordinary operation exposed an ordering error between deletion and the bookkeeping that follows a mutation. The RENAME fix describes a failed check when both keys belonged to the same shard. Deleting a key could invalidate an iterator that the post-update operation still intended to use.

Dragonfly 1.14.2, released on February 5, includes that correction alongside replication and memory-management fixes. The patch is useful precisely because the client-facing commands remain familiar. Their implementation still has to coordinate object lifetime and journal records, including paths that optimize work within one shard.

I favour Dragonfly when a larger single cache process can keep the deployment manageable. That preference makes the correctness of its internal shard boundaries important. A command that stays within one shard must remain correct even when it takes a different execution path from a command that crosses shards.

Deletion changes what an updater can assume

The rename patch moves the destination's post-update work before deletion of the source. It also sets the destination's sticky flag before running that updater. These are small code movements, but they change which assumptions remain valid when the updater runs. The pull request explains that running post-update after deletion was illegal because deletion could invalidate iterators.

The accompanying regression test deliberately configures a single thread. It creates x and y, then renames x over y and expects success. That setup removes uncertainty about whether the two keys happen to land on different shards. The test covers the exact arrangement the bug requires, including an already existing destination.

SET x value
SET y value
RENAME x y

This example follows the test's command sequence. It describes a case fixed by the release, without claiming that every rename previously failed. The existing destination and same-shard placement explain why an application could use renames successfully for some keys and still encounter the crash on others.

A separate automatic-updater change addresses the same class of iterator assumptions more defensively. Its new helper checks whether an iterator is occupied and still points to the expected key. If either condition fails, it finds the key again. The patch also changes database-size and deletion-count checks into debug checks.

The author calls this a temporary fix. That qualification matters when interpreting the patch. Reacquiring an iterator addresses a particular failure path, while the debug checks continue to express assumptions about database mutation. It would overstate the source to describe this change as a complete redesign of mutation handling. The release combines a specific ordering correction with protection around updater state.

Script execution must finish its journal record

The replication backport adds journal completion after an optimized script-execution path. Its transaction constructor already uses a squashed execution mode for single-shard scripts. The fix records whether that execution wrote journal entries and emits an EXEC journal operation when required.

This explains the failure more precisely than a general statement about unstable replication. The replica's transaction reader assembles commands until it reaches the completion record. Executing a script on the primary and recording its component operations are insufficient if that record never arrives. The patch connects script completion with completion of the journal representation that replicas consume.

The regression test creates a primary and two replicas, runs generated scripts that increment several keys, and compares the resulting values on both replicas. It varies the number of keys included in each script, including a script with no keys. Those cases exercise execution paths whose journal details differ even though the application sees the same EVAL interface.

I place more weight on that explanation than on the patch version's size. A replication correction matters to any deployment using the affected script path and replicas, even if the primary returns the expected command result. The application-visible result and the replica's ability to finish applying the operation are separate observations.

Empty strings remain values inside queued commands

Another fix in the release corrects storage of zero-length command arguments. The old code copied an extra byte for a terminator. The new code sizes the combined buffer using the actual argument lengths and copies bytes only for nonempty arguments. Argument sizes remain separate metadata.

Its test queues a SET with an empty string inside MULTI, executes it, and reads the key back. That is a useful boundary case because an empty value still represents a real argument. Queueing the command must preserve it through the stored-command representation. Treating empty input as an absent argument would change the meaning of a valid request.

The JSON allocator change completes the patch's memory-related work. It changes the JSON type to the library's polymorphic-allocator form and passes Dragonfly's memory resource when parsing a JSON string. It also moves JSON object creation during snapshot loading to the shard thread. These changes associate object construction with the intended allocation context.

That source does not supply a general reduction in memory usage or a performance percentage. Its practical contribution is control over where JSON allocations originate, including during recovery. Alongside the rename and replication corrections, it shows why a maintenance release can deserve attention without adding a new command. Version 1.14.2 repairs the internal representations that preserve existing command behaviour during mutation, queued execution, and replication.