• Binbin's avatar
    Add command being unblocked cause another command to get unblocked execution order test (#12324) · 9dc6f93e
    Binbin authored
    * Add command being unblocked cause another command to get unblocked execution order test
    
    In #12301, we observed that if the
    `while(listLength(server.ready_keys) != 0)`
    in handleClientsBlockedOnKeys is changed to
    `if(listLength(server.ready_keys) != 0)`,
    the order of command execution will change.
    
    It is wrong to change that. It means that if a command
    being unblocked causes another command to get unblocked
    (like a BLMOVE would do), then the new unblocked command
    will wait for later to get processed rather than right away.
    
    It'll not have any real implication if we change that since
    we do call handleClientsBlockedOnKeys in beforeSleep again,
    and redis will still behave correctly, but we don't change that.
    
    An example:
    1. $rd1 blmove src{t} dst{t} left right 0
    2. $rd2 blmove dst{t} src{t} right left 0
    3. $rd3 set key1{t}, $rd3 lpush src{t}, $rd3 set key2{t} in a pipeline
    
    The correct order would be:
    1. set key1{t}
    2. lpush src{t}
    3. lmove src{t} dst{t} left right
    4. lmove dst{t} src{t} right left
    5. set key2{t}
    
    The wrong order would be:
    1. set key1{t}
    2. lpush src{t}
    3. lmove src{t} dst{t} left right
    4. set key2{t}
    5. lmove dst{t} src{t} right left
    
    This PR adds corresponding test to cover it.
    
    * Add comment near while(listLength(server.ready_keys) != 0)
    9dc6f93e
blocked.c 32.3 KB