• debing.sun's avatar
    Fix incorrect lag due to trimming stream via XTRIM command (#13473) · 11c40358
    debing.sun authored
    ## Describe
    When using the `XTRIM` command to trim a stream, it does not update the
    maximal tombstone (`max_deleted_entry_id`). This leads to an issue where
    the lag calculation incorrectly assumes that there are no tombstones
    after the consumer group's last_id, resulting in an inaccurate lag.
    
    The reason XTRIM doesn't need to update the maximal tombstone is that it
    always trims from the beginning of the stream. This means that it
    consistently changes the position of the first entry, leading to the
    following scenarios:
    
    1) First entry trimmed after maximal tombstone:
    If the first entry is trimmed to a position after the maximal tombstone,
    all tombstones will be before the first entry, so they won't affect the
    consumer group's lag.
    
    2) First entry trimmed before maximal tombstone:
    If the first entry is trimmed to a position before the maximal
    tombstone, the maximal tombstone will not be updated.
    
    ## Solution
    Therefore, this PR optimizes the lag calculation by ensuring that when
    both the consumer group's last_id and the maximal tombstone are behind
    the first entry, the consumer group's lag is always equal to the number
    of remaining elements in the stream.
    
    Supplement to PR https://github.com/redis/redis/pull/13338
    11c40358
t_stream.c 158 KB