Feature Request: Support CLIENT REPLY OFF/ON/SKIP subcommands

[sspeaks]

Feature request type

enhancement

Is your feature request related to a problem? Please describe

Problem

Garnet does not support the CLIENT REPLY subcommand. Sending CLIENT REPLY OFF returns:

(error) ERR unknown subcommand 'REPLY'. Try CLIENT HELP.

Redis has supported CLIENT REPLY OFF|ON|SKIP since version 3.2.

Why It Matters

CLIENT REPLY OFF is used to implement fire-and-forget pipelines — a common pattern for high-throughput bulk writes. The client sends a batch of commands without reading responses, relying on CLIENT REPLY OFF to suppress server replies entirely. This avoids both the
overhead of parsing responses and the risk of TCP backpressure from unread reply data accumulating in kernel buffers.

Without this support, bulk write pipelines that use CLIENT REPLY OFF will deadlock under Garnet. The server continues sending +OK replies for every command, the client never reads them, and eventually the TCP send buffer fills up. The server then blocks trying to write to the socket, while the client blocks trying to send more commands — a classic TCP deadlock.

This affects any client library or tool that relies on CLIENT REPLY OFF for pipelining, including:

• redis-cli --pipe (Redis's built-in mass insertion mode)
• Custom bulk loaders and cache warmers
• Client libraries with fire-and-forget APIs

Reproduction

127.0.0.1:6379> CLIENT REPLY OFF
(error) ERR unknown subcommand 'REPLY'. Try CLIENT HELP.

For the deadlock scenario:

# In a pipeline, send:
CLIENT REPLY OFF
SET key1 value1
SET key2 value2
... (repeat ~100K times)
CLIENT REPLY ON
# Client hangs after ~66K-119K commands — server is blocked writing
# unread +OK responses, client is blocked writing new commands.

Current CLIENT Subcommand Support

Garnet already supports several CLIENT subcommands:

Subcommand	Supported
GETNAME	✅
ID	✅
INFO	✅
KILL	✅
LIST	✅
SETINFO	✅
SETNAME	✅
UNBLOCK	✅
REPLY	❌

Reference

• Redis documentation: https://redis.io/docs/latest/commands/client-reply/
• CLIENT REPLY accepts three modes:
  • OFF — suppress all replies until ON is sent
  • ON — resume normal replies (this reply itself is sent)
  • SKIP — suppress the reply for the next command only

Describe the solution you'd like

Add support for CLIENT REPLY [OFF|ON|SKIP]

Describe alternatives you've considered

No response

Additional context

No response