[MDA2AV]

A busy redis connection began refusing every command with pipelined send buffer full after 512 KiB of traffic, even though only one command was waiting to be sent.

The sender sent [_sendOffset, _sendEnd) and moved both back to 0 only when a send completed with nothing appended behind it. On a connection where a command is always appended while a send is in flight, that never happens, so _sendEnd only grew until it reached the fixed 512 KiB buffer. Only a send that happened to drain the buffer fully reset it, so until then every new command was refused (with PINGs, from about the 37,000th on). pg had the same loop and fixed it in ce82399.

The sender now sends a snapshot of the staged bytes, and once that is out it moves whatever was appended meanwhile to the front, exactly as PgConnection does. No new state.

Tests

New, in RedisSendBufferTests:

• redis: a connection whose sends never fully drain still reuses its send buffer

The test drives a real RedisConnection through a scripted IRingHost. The scripted ring completes the connect at once and holds each send and recv until the test completes it, inline, as a reactor would. That makes the interleaving exact: each PING is appended before the previous send completes, and every reply is delivered. The test pushes 4 x 512 KiB through one connection. It checks that every command is answered PONG, and that the bytes sent are exactly the PINGs in order, so the compaction cannot corrupt the stream unnoticed. It needs no redis. The scripted ring accepts timeouts and never fires them, so the test also runs unchanged on top of the open-deadline branch, whose ConnectAsync arms one.

	main	this PR
PINGs through one connection that never drains	command 37,450 refused at 524,272 bytes sent	all 149,798 sent and answered

A loopback probe (not committed) did not trigger the bug: 64 workers sending 20,000 PINGs each on one connection to the real redis, 1,280,000 PINGs refused 0 times on main. On loopback the send completes before the next command arrives often enough that the buffer drains. The bug needs a send still in flight at each append, for example on a busy reactor, a slower link, or a full socket buffer.

Suites: Unit 63 (1 pending, as on main), Pg 6, Redis 4, with both sidecars running (nothing skipped).

Hot path: the redis sender loop runs for every command. It now does one snapshot and, when something was appended during the send, one memmove of that tail per send cycle. pg has run this loop since ce82399. Worth a wrk before/after on a quiet box.

Bench: the sender loop now compacts after every snapshot, a memmove of whatever was appended during the send. A redis wrk before/after will follow here once the box is quiet.

[MDA2AV]

Bench, before/after:

sample	main	this PR
Clients/Redis	371,641 req/s, 5.13 us/req (5.11-5.13)	375,405 req/s, 5.07 us/req (5.02-5.09)

No cost: the compaction is a memmove of what was appended during the send.

Method: bench/any.sh (wrk), 2 reactors, 64 connections, 8 threads, 10 s per cell, server pinned to P-cores 0-7,10-15, all cells saturated. 3 rounds, each branch run right after main (f298af0) in the same round, so drift lands on both. Median (min-max) of the 3.

[MDA2AV]

Closing: ioxide.redis is being dropped in #337 (StackExchange.Redis on the reactor's ring, #335, takes its place), so this fix has nothing left to land in. The branch stays, so this can be reopened if the drop doesn't go ahead.