Fix assertion crash in processIOThreadsReadDone when DONT_PARSE client has stale argc

[aradz44]

Found while reading the code — I have not yet been able to confirm whether this path can materialize in existing real-world scenarios.

Bug

When an IO thread reads from a client with READ_FLAGS_DONT_PARSE set (because canParseCommand returns 0), processIOThreadsReadDone skips handleParseResults but still checks c->argc > 0 and sets pending_command = 1. However, argc may be stale from a previous incomplete pipelined command parse — it was set by consumeCommandQueue when handleParseResults returned PARSE_NEEDMORE, and was never cleared.

This leads to processCommand being called with parsed_cmd == NULL and without READ_FLAGS_COMMAND_NOT_FOUND, triggering the assertion:

==> server.c:4177 'c->read_flags & READ_FLAGS_COMMAND_NOT_FOUND' is not true

Crash sequence

1. IO thread parses pipelined commands; the last command is incomplete → cmd_queue entry has argc > 0, parsed_cmd = NULL
2. Main thread consumeCommandQueue pops the incomplete entry → c->argc > 0, c->parsed_cmd = NULL
3. handleParseResults returns PARSE_NEEDMORE → loop breaks, stale argc remains on the client
4. An external event makes canParseCommand return 0 for this client (e.g. close_after_reply, close_asap, or application-specific blocking flags)
5. New data arrives → trySendReadToIOThreads sets READ_FLAGS_DONT_PARSE
6. IO thread reads data, skips parsing
7. processIOThreadsReadDone: stale argc > 0 → pending_command = 1
8. processCommand: parsed_cmd == NULL, COMMAND_NOT_FOUND not set → assertion crash

Fix

In processIOThreadsReadDone, when DONT_PARSE is set and argc > 0, skip the client. The argc is stale from a previous incomplete parse — the IO thread didn't parse anything new, so there is no valid command to execute.

Test

Added DEBUG SET-CLOSE-AFTER-REPLY subcommand and a test that reproduces the crash deterministically:

1. Client sends a complete PING + incomplete SET (truncated value) in one pipeline
2. After PING reply confirms the incomplete parse was consumed (stale argc), DEBUG SET-CLOSE-AFTER-REPLY is called from another connection to simulate the external event
3. Client sends remaining data → triggers the DONT_PARSE path → crash on unfixed server

[ranshid]

I think what we wanted is a debug extended CLIENT KILL abilities right?
maybe it would be helpful to have a debug command: DEBUG CLOSE-ASAP (close async) and DEBUG CLOSE-AFTER-REPLY ?

[madolson]

Presumably this would be reproducible after doing ACL LOAD with the current user getting invalidated. In that case we call close_after_reply. That seems like a real potential crash? If we can trigger this with a real known workload, I would feel a bit better about it than something synthetic.

[ranshid]

Agree. better to fix and test REAL issue rather than a synthetic one. Good point about the ACL LOAD!

[aradz44]

close_after_reply is only set by a client on itself by what I saw , but a client can't have both stale argc and close_after_reply because
setting close_after_reply requires executing a command, which calls resetClient and zeros argc, and once it's set. For external paths like ACL LOAD, the code uses freeClientOrCloseLater which sets close_asap (not close_after_reply),
and close_asap is already guarded by trySendReadToIOThreads.
If you think of another way to trigger it I can check it.

[aradz44]

Sorry for the push -f I forgot to add -s to the commit