Valkey restores the API names expected by Redis modules
Valkey 7.2.6 fixes a duplicated API-name registration that could crash existing Redis modules during loading. Binary compatibility depends on runtime names as well as headers.
A compatibility layer can contain the right implementation and still fail if a module cannot find it under the name it expects. Valkey 7.2.6, published on July 31, fixes exactly that kind of problem. Its API registration macro registered the Valkey-prefixed name twice instead of also registering the corresponding Redis-prefixed name.
The release notes give the release moderate urgency and identify incompatibility with modules compiled for Redis as the main reason. They describe potential segmentation faults during loading. For users without those modules, the release primarily addresses other uncommon defects. That scope makes the module mechanism the useful focus of this patch.
I favour Valkey's continuation of the Redis model, and I have used the underlying technology since its release. Keeping existing module integrations usable is part of that preference. A familiar command protocol cannot compensate for a module that fails before its own commands become available.
A runtime API has names as well as functions
The fix in pull request 608 changes the second line of REGISTER_API. The macro's intent is to register both project-prefixed names against one implementation. In the corrected form, a function suffix produces a ValkeyModule_ name and a RedisModule_ name, both pointing to the corresponding internal function.
The error was a duplicated string prefix in the server's central API registration macro. Registering the Valkey name again did not provide an alias for the earlier name. A previously compiled module expecting the Redis API could therefore fail to obtain the function through the compatibility path. The source comments explicitly identify preserving legacy Redis module binaries as the reason for registering both forms.
This is more specific than an unspecified ABI mismatch. The patch does not replace the entire module loader or change every function's calling convention. It corrects the names inserted into the runtime API registry. The implementation functions are already there, and the missing part is exposing them through the second naming convention.
The module source in 7.2.6 shows that the registry participates in module-system initialization. During setup, the server calls core API registration. Those names need to exist when modules initialize, so a failure at this stage can prevent an otherwise usable server extension from loading.
The registration function stores the function pointer in a dictionary under the supplied name. The compatibility alias therefore needs its own dictionary entry even when the implementation pointer is identical. Registering the same spelling a second time cannot stand in for inserting another key. This is the concrete data-structure relationship behind the macro change.
It is also why the corrected prefix does not require two implementations of each API function. Both names resolve to the same internal function pointer. Compatibility here adds another lookup route to existing behaviour, so the server can maintain one implementation while satisfying modules built around either public naming convention.
Header compatibility is a separate property
The earlier 7.2.5 release notes introduced a Valkey module header while retaining the Redis module API for source compatibility. They also stated an intention to support existing module binaries. Those are related goals, but they require different mechanisms.
A source build can compile using declarations and naming conventions available in its headers. A compiled module arrives with expectations already encoded in its initialization code. The running server needs to satisfy those expectations through its runtime API. Preserving a header in a source tree does not by itself establish that the server registers the names requested by an existing binary.
That distinction explains why a small macro change has operational significance. A module's author may not rebuild it at the same time the server package changes. Keeping the runtime aliases working supports that independent release schedule. The correction addresses the compatibility contract at the point the old binary actually consumes it.
It also illustrates why a server's own version response is incomplete evidence for module compatibility. Product identification can correctly report Valkey while a particular extension still encounters another interface. The protocol response and the module registry serve different consumers. A complete integration depends on the interface the component uses, not merely on the server accepting ordinary client commands.
Other fixes affect blocked work and cluster state
The 7.2.6 notes also list command-duration and timeout corrections for blocked clients whose commands are reprocessed. Those fixes concern an operation's lifecycle beyond its first dispatch. A command that waits and resumes needs accounting that continues to describe the same operation. The release identifies separate corrections to duration reset and blocking timeout reset behaviour.
The cluster fixes include more accurate slot information from CLUSTER SHARDS when a primary fails. That is relevant to tools and clients interpreting topology during failure, when accurate metadata is particularly useful. The notes also describe improving MEET reliability under link failures to maintain symmetric cluster membership. These are specific cluster behaviours rather than consequences of the module registration error.
Sentinel startup receives a naming-compatibility correction as well. The release accepts the earlier redis-sentinel name for entering Sentinel mode. This is another case where a name carries behaviour. A compatibility executable name has to select the expected mode, not merely locate some executable that can run.
Those supporting fixes make the release broader than the API macro correction, but they do not obscure its main urgency. Users loading modules compiled for Redis have a concrete incompatibility addressed here. Other users receive several correctness fixes without a new application data model.
My preference is to assess compatibility at the actual integration boundary. For an existing module, that includes runtime API names and initialization behaviour. In 7.2.6, the corrected macro registers both naming conventions against the same implementation, so the server once again supplies the Redis-prefixed lookup names its compatibility design intended.