The kernel socket buffer holds the fragments until the full command arrives, so Redis only ever reads complete commands, exactly as it reassembles fragmented packets before delivering them.

The event loop keeps one global staging buffer shared by all clients, flushed whenever any command completes.

The database stores a partial entry for the command, finalizing it when the remaining bytes arrive.

The client object remembers the unfinished input in its input buffer; the database should only see complete commands and server state.

The server should keep writing in a loop until all 100 bytes are sent, since replies must never be split across loop iterations.

The client output buffer must keep the remaining 90 bytes and the connection must stay registered for writable progress.

Nothing needs saving; the reply can be regenerated from the command result on the next loop tick.

The 90 bytes can be dropped, because RESP clients detect truncated replies and reissue the original command.

All three dispatch commands identically; only the format of the replies differs between the modes.

A transaction client executes commands immediately but withholds replies until EXEC, while a subscribed client buffers its commands until UNSUBSCRIBE, so that EXEC and UNSUBSCRIBE can release the held results in a single batch.

A normal client dispatches commands immediately, a transaction-building client queues queueable commands, and a subscribed client accepts only subscription-mode commands.

A subscribed client can run any command but also receives pushes, while a transaction client rejects everything except EXEC.

Later publishes will try to push messages to a dead client, causing stale fanout entries, wasted work, or output-buffer errors.

Publishes to that channel will start failing with an error until the dead entry is removed from the set.

New subscribers will be blocked from joining the channel because the dead client still occupies its registration slot until the dead one times out and its slot is reclaimed.

Nothing observable happens, because delivery checks liveness before each push and silently skips closed clients.

Freeing the client object is enough, since event registrations and index entries are reclaimed automatically with it.

Flush all pending output to the socket first, then free the object; side indexes clean themselves on the next publish.

Only the socket must be closed; per-client state is reset lazily when the file descriptor number is reused by a new connection.

Closing must stop file events, release pending output, remove the client from Pub/Sub side indexes, clear watched or transaction state, and free the client object.