Summary
process_message() is doing too much
The process_message() function currently handles all opcode dispatching and command logic inline, making it a large monolithic function. This hurts readability, makes it harder to test individual commands in isolation, and increases the cognitive load when working on any single handler you have to navigate through all of them.
Each command handler also depends on a shared set of references (storage, stream, metrics, cluster, session, user_store) that are threaded through manually, adding noise to the function body.
As more opcodes are added, this structure will scale poorly.
Replication logic is duplicated across handlers
The pattern of creating a ReplicationEntry and calling replicate_async() is repeated nearly identically across many different command handlers. This duplication means that any change to the replication flow
Acceptance Criteria
Summary
process_message()is doing too muchThe process_message() function currently handles all opcode dispatching and command logic inline, making it a large monolithic function. This hurts readability, makes it harder to test individual commands in isolation, and increases the cognitive load when working on any single handler you have to navigate through all of them.
Each command handler also depends on a shared set of references (storage, stream, metrics, cluster, session, user_store) that are threaded through manually, adding noise to the function body.
As more opcodes are added, this structure will scale poorly.
Replication logic is duplicated across handlers
The pattern of creating a ReplicationEntry and calling replicate_async() is repeated nearly identically across many different command handlers. This duplication means that any change to the replication flow
Acceptance Criteria