[NEW] Linearization log

[knggk]

The problem/use-case that the feature addresses

Steady-state workloads on Valkey primaries should be linearizable, by virtue of commands from all client connections being executed on a single thread. Ultimately the source of truth for the linearization of a workload is what happens on this single thread. This information is only partially exposed today:

1. The replication stream would be a linearization of commands; however 1) only of write commands 2) without info on which client ran which command
2. MONITOR provides a linearization of commands, but only if the workload is restricted to non blocking commands

To see what is meant by 2: right now blpop x 0 followed by lpush x 42 on another client show up in MONITOR as:

1685565207.356311 [0 127.0.0.1:44574] "blpop" "x" "0"
1685565227.593105 [0 127.0.0.1:35492] "lpush" "x" "42"

However the correct linearization would be lpush and then blpop. The blocking pop is effectively executed after the lpush: once data has become available in list x.

Description of the feature

This issue is a proposal to create a variant of monitor that logs the true linearization of the workload running on the primary, including blocking commands. A prototype could demo this on the list type, and later be extended to other data-types such as streams.