Redis 7.2 RC1 makes AOF acknowledgement explicit

Receiving a write acknowledgement and knowing that an append-only file has reached disk are different observations. Redis 7.2's first release candidate introduces WAITAOF to make the second observation available to a client connection. The command lets a caller request local and replica persistence acknowledgements for its preceding writes, with an explicit timeout.

The 7.2 release notes date RC1 to March 22. The notes pinned to that candidate describe it as an early version for community testing and explicitly exclude production suitability. That distinction matters when discussing a new durability-related command, since an available implementation is still under release-candidate evaluation.

I have used Redis since its early releases, and I appreciate an interface that exposes a persistence requirement directly. An application can make a more precise decision when the result distinguishes local disk acknowledgement from replica acknowledgement. The new command's scope is the important part of that precision.

The requirement belongs to the current connection

The candidate's command definition defines arguments for the required local count, replica count, and timeout. It describes the operation in terms of preceding writes sent through the current connection. The reply is a two-element array containing the observed local and replica counts.

The implementation accepts a local requirement of zero or one. It parses a nonnegative replica requirement and a timeout in milliseconds. When a local acknowledgement is required, it rejects the request if append-only persistence is disabled.

A client can express a requirement for the local AOF and one replica with the following illustrative command. It must run on the same connection as the writes whose progress matters.

WAITAOF 1 1 1000

The local requirement is bounded to one because it refers to the contacted primary. The replica requirement can describe multiple remote acknowledgements. Those separate domains explain why the implementation validates the two count arguments differently.

The numeric arguments request one local acknowledgement and one replica acknowledgement, with a one-second timeout. The command itself does not issue the preceding write or enable AOF. Connection-pooling code needs to preserve that connection relationship when it exposes the operation to an application.

The implementation checks the client's last write offset. It compares the local fsynced replication offset with that position and counts replica AOF acknowledgements that have reached it. That gives the wait a concrete position in the stream of writes, rather than asking whether the server has ever synchronized any data.

Waiting is conditional on observed progress

If the observed counts already meet the request, the command can reply without blocking. Otherwise, it registers the connection among clients waiting for replication acknowledgements. Processing later acknowledgements can release clients whose required offsets and counts have become satisfied.

The two reply values preserve useful information. A caller can distinguish the local persistence observation from the number of replicas that reached the relevant point. Treating any array response as an undifferentiated success would discard the information needed to assess the requested condition.

The implementation rejects use against a replica instance. Its error explains that writes made to a replica are local and are not propagated. This prevents a caller from confusing a local operation on a replica with the primary's replication stream that the command is designed to observe.

The candidate also changes WAIT to use the replication offset after the client's last write, instead of its last command. That is a related refinement of scope. A read issued after a write should not silently redefine which write progress the caller intended to wait for.

Persistence acknowledgement is a specific guarantee

WAITAOF exposes an observation about the relevant AOF progress. It does not change every write command into a transaction whose outcome can be inferred from an unrelated connection. The same-connection definition and returned counts need to remain visible in a client library's contract.

This distinction is especially important after a lost response. The application may know that it sent a write but lack a usable reply. A later persistence wait is useful only within its defined relationship to the connection and offset. The command definition does not supply an application-level operation identifier for deciding whether to repeat an uncertain business operation.

I prefer making those boundaries explicit because durability requirements tend to become vague in application code. A request for a local synchronized file and a request for one replica are now distinct arguments with distinct reply values. The application still needs to decide what it will do when its required observation is unavailable.

The candidate also changes compatibility assumptions

The candidate notes introduce RDB format version 11 and state that older Redis versions cannot read it. That is a concrete compatibility boundary for snapshot files. A release candidate evaluation involving saved data must therefore account for which server will later read the produced file.

Module users have additional changes to examine. The notes identify restrictions on registering commands, configurations, and data types after the module's load handler. They also describe changes to module calls and notification behavior. A module that loads successfully is not, by that fact alone, evidence that every integration path preserves its previous behavior.

Other behavior changes affect applications without modules. Client-side tracking for scripts now follows keys actually read by the script, rather than the keys declared by the caller. Blocked commands re-evaluate conditions such as ACL permissions and out-of-memory policy when they resume. These changes make runtime behavior depend on what executes and the state at execution time.

The release candidate also introduces CLIENT SETINFO, which lets a client library report its name and version. The notes add corresponding library fields to CLIENT LIST. That information can help identify which client implementation produced a connection when investigating the new persistence calls or other changed behavior.

RC1 therefore offers more than a list of commands to try. It exposes a defined persistence observation and changes several compatibility assumptions around saved files and execution. The practical evaluation starts with the exact connection and AOF requirements, then accounts for the file format and application behavior that the candidate can change.