fix(stream): saturate pending_number decrements and clamp lag to INT64_MAX [FaaFyfxR9WAQrL7FcAgEHJvztd8cVMxvjHRS55rw1nwH]

[waterWang]

This PR addresses the remaining instances of the same failure class described in #3578 (merged): non-saturating pending_number decrements and lag values exceeding INT64_MAX.

Changes

1. Saturating pending_number decrements

Following the pattern established in #3578, all remaining unconditional -= operators on pending_number now use saturating arithmetic (clamp to 0):

• DeleteConsumer (XGROUP DELCONSUMER): group.pending_number -= deleted_pel — cross-level subtraction, highest risk since it subtracts a consumer's count from the group's count.
• DeletePelEntries (XACK): group.pending_number -= *acknowledged and consumer.pending_number -= ack_count.
• ClaimPelEntries (XCLAIM): original_consumer.pending_number -= 1.

2. Clamp lag to INT64_MAX

lag is a uint64_t stored in group metadata, but it's emitted as a RESP integer that clients parse as signed 64-bit. entries_added can be set to any uint64_t via XSETID ... ENTRIESADDED n, so a correctly-computed lag = entries_added - entries_read can legitimately exceed INT64_MAX.

Both CheckLagValid computations now clamp to INT64_MAX via std::min.

Verification

All changes follow the same saturating pattern from #3578:

value = value >= decrement ? value - decrement : 0;

No behavioral change for normal operation — clamping only activates on already-corrupt data or extreme entries_added values.

[github-actions]

Hi @waterWang,

Thank you for your pull request. Please review our Contributing Guide.

Please make sure you understand your changes and explain your reasoning in this pull request. Low-quality pull requests may be closed.

[PragmaTwice]

Closed due to AI policy. Feel free to reopen.