Skip to content

Replace INCREX out-of-bounds policy to a single SATURATE option#15237

Merged
sundb merged 8 commits into
redis:unstablefrom
sundb:remove-overflow-and-fail
May 20, 2026
Merged

Replace INCREX out-of-bounds policy to a single SATURATE option#15237
sundb merged 8 commits into
redis:unstablefrom
sundb:remove-overflow-and-fail

Conversation

@sundb

@sundb sundb commented May 20, 2026

Copy link
Copy Markdown
Collaborator

Follow #15045

Summary

Simplify INCREX's out-of-bounds policy:

The original INCREX shipped with three out-of-bounds policies — OVERFLOW FAIL, OVERFLOW SAT, OVERFLOW REJECT — but FAIL and REJECT are functionally redundant: both leave the key untouched when the result is out of bounds. They differ only in how the caller is notified (error reply vs. [current_value, 0] array reply), which forces the user to make a stylistic choice with no real semantic difference.

This PR collapses the three policies into one clear behavior:

  • Default: the operation is rejected; the key value and TTL are left unchanged, and the reply is [current_value, 0]. Callers detect non-application by checking the applied-increment field; no error-handling branch is required.
  • SATURATE: the result is saturated to UBOUND / LBOUND, or to the type limits (LLONG_MAX/MIN for BYINT, ±LDBL_MAX for BYFLOAT) when no explicit bound is given.

New syntax:

INCREX <key> [BYFLOAT increment | BYINT increment]
             [LBOUND lowerbound] [UBOUND upperbound] [SATURATE]
             [EX seconds | PX milliseconds | EXAT seconds-timestamp | PXAT milliseconds-timestamp | PERSIST] [ENX]

Note

The syntax above was updated in #15237


Note

Medium Risk
Changes INCREX client-visible semantics and reply formats for out-of-bounds/overflow cases (errors become [current_value, 0] rejections), which may impact existing clients relying on previous OVERFLOW policies.

Overview
INCREX no longer accepts OVERFLOW <FAIL|SAT|REJECT>; it now supports a single optional SATURATE flag in command metadata (commands.def, commands/increx.json) and in argument parsing.

Runtime behavior in increxCommand changes so out-of-bounds/overflow operations default to a non-error rejection (key/TTL unchanged, reply [current_value, 0]), while SATURATE clamps to LBOUND/UBOUND (or type limits) and proceeds. Tests are updated accordingly and the former OVERFLOW REJECT coverage is removed.

Reviewed by Cursor Bugbot for commit c0f7ec6. Bugbot is set up for automated code reviews on this repo. Configure here.

@sundb sundb requested review from ShooterIT, oranagra and tezc and removed request for tezc May 20, 2026 07:29
Comment on lines -347 to -367
# ---------------------------------------------------------------------
# OVERFLOW REJECT: leave the key (and TTL) unchanged and reply
# [current_value, 0] when the result would be out of bounds, instead of
# producing an error.
# ---------------------------------------------------------------------

test {INCREX - BYINT REJECT on overflow leaves value unchanged, in-range applies normally} {
# llong overflow path
r set mykey 9223372036854775800
assert_equal [r increx mykey BYINT 9223372036854775800 OVERFLOW REJECT] {9223372036854775800 0}
assert_equal [r get mykey] 9223372036854775800
# UBOUND / LBOUND paths
r set mykey 10
assert_equal [r increx mykey BYINT 100 UBOUND 15 OVERFLOW REJECT] {10 0}
assert_equal [r increx mykey BYINT -100 LBOUND 5 OVERFLOW REJECT] {10 0}
assert_equal [r get mykey] 10
# In-range increment is applied normally
assert_equal [r increx mykey BYINT 3 UBOUND 20 OVERFLOW REJECT] {13 3}
assert_equal [r get mykey] 13
}

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since a large number of tests have already been done on the default policy, there is no longer any need for it.

Comment thread src/t_string.c Outdated
sundb and others added 2 commits May 20, 2026 15:49
Co-authored-by: Ozan Tezcan <ozantezcan@gmail.com>
Comment thread src/t_string.c
@sundb sundb merged commit 95040d6 into redis:unstable May 20, 2026
19 checks passed
@github-project-automation github-project-automation Bot moved this from Todo to Done in Redis 8.8 May 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants