Dragonfly 0.3 adds a limited Streams implementation

A server can improve client compatibility by accepting less. Dragonfly 0.3.0 changes its HELLO handling so clients do not mistake partial support for a complete protocol negotiation facility. The same June 15 alpha release introduces preliminary Streams support. Together, these changes show why compatible command names need precise limits on the behavior they advertise.

The release notes identify Lettuce, the Java client, as a beneficiary of the handshake fix. They describe Streams as preliminary rather than complete. That qualification matters because the implemented storage operations do not yet include the full consumer workflow commonly associated with the command family.

I find Dragonfly's multicore design interesting when a cache needs more capacity from one machine. Client compatibility determines how much of that design an existing application can actually use. An accurate failure response can therefore be as useful to adoption as another implemented command.

HELLO is also a capability signal

Pull request 129 explains the handshake problem. Some clients interpret the presence of HELLO as evidence that RESP3 is supported, because the command and protocol appeared together in Redis. Dragonfly's implementation did not support that full behavior and did not reject all unsupported arguments correctly.

The patch allows the supported no-argument form and protocol version 2. For unsupported forms, including protocol version 3 and extra authentication arguments, it responds as an unknown command. The source comments explain that this lets clients fall back to RESP2 and use the separate AUTH command.

This is a specific compatibility strategy. A more general protocol error and an unknown-command response can cause a client to make different decisions. Returning a superficially plausible HELLO response is insufficient if the client then assumes it can exchange messages the server does not support.

The regression tests cover both the accepted reply and rejected forms. They check protocol information in the accepted response and errors for unsupported combinations. Those tests make the capability boundary more concrete than a single checked box beside HELLO.

This behavior also shows why authentication is part of connection compatibility. A client may try to negotiate a protocol and authenticate within the same command. Implementing only a minimal server-information reply cannot silently satisfy that combined request. The revised handling tells the client to take a supported route.

Streams arrive as an explicit subset

The API status document at v0.3.0 lists the implemented stream commands. These include adding and deleting entries, obtaining length, and reading ranges in either direction. Several group-management subcommands are marked implemented too.

However, the document leaves XREAD and XREADGROUP unchecked. It also leaves pending-entry inspection and claiming commands unchecked. Creating group metadata is consequently different from supporting the entire process of delivering entries to group consumers and managing outstanding deliveries.

That distinction limits what the release can be called. A program using range operations can exercise useful stream functionality. A program whose stream abstraction depends on XREADGROUP still needs an operation the table says is absent. Neither program's compatibility can be inferred merely from the presence of the Stream family heading.

The initial list also marks XTRIM as absent. The partial-streams patch nevertheless implements a MAXLEN option for XADD. This is an example of why command-level and option-level details both matter. Retention can be available during append without a separate trimming command being available.

Append and range operations have useful independent meaning

The stream patch contains an append test that adds a field-value entry using an automatically generated identifier. A basic interactive sequence can therefore demonstrate the supported storage operations without suggesting that the server implements a consumer queue.

XADD events * kind created
XLEN events
XRANGE events - +

The first command appends an entry, the second asks for the number of entries, and the third reads the range. This example deliberately uses commands listed as implemented in the tagged API status. It does not rely on blocking reads or group delivery.

The append implementation validates the argument arrangement and parses the requested identifier before scheduling the operation on the owning shard. It constructs field-value objects for the underlying stream operation and releases those temporary references afterward. The patch therefore adds the command's data manipulation and memory-handling work, not just registration of a command name.

For MAXLEN, the implementation parses the requested maximum and supports the approximate marker before invoking length trimming. That provides an append-time control on the stored collection. It should not be extrapolated into support for every modern XADD option, because the parser shown in this release has a narrower scope.

An alpha needs more than a command count

The release also fixes a rare transaction deadlock and a nested-array parser issue. These are different forms of correctness work from extending API coverage. A command implementation must coexist with concurrency scheduling and the protocol parser before an application can use it reliably.

Dragonfly's 0.3 notes explicitly label the release alpha. That status is consistent with the incomplete API table and the handshake correction. The project is identifying and repairing assumptions in the ways clients connect as well as adding operations after connection.

I prefer the explicit support table to a broad replacement claim because an application's dependency can be very small and still precise. A single missing read mode may matter more than dozens of unrelated implemented commands. Conversely, an application that needs only append and range storage may be able to use the initial subset meaningfully.

The alpha also adds a quick-start guide and contribution infrastructure, according to its release notes. Those additions give compatibility reports a more direct route into reproducible changes, alongside the command-specific fixes already included in this release.

The June release makes progress on both sides of that boundary. Streams gain concrete storage operations, while HELLO stops suggesting capabilities that the server does not provide. The practical compatibility question is which commands and negotiation paths the actual client uses, and the tagged sources now give a more accurate answer for those cases.