Reject NAN scores in listpack/ziplist-encoded sorted sets on RDB load by madolson · Pull Request #3921 · valkey-io/valkey

madolson · 2026-06-05T03:46:07Z

Problem

A crafted RESTORE payload can store a NAN score in a listpack-encoded sorted set. The integrity validation (lpValidateIntegrityAndDups) only checks the listpack structure and member uniqueness — it does not check score validity — so the payload is accepted on load.

When the sorted set is later converted to a skiplist (e.g. when it grows past zset-max-listpack-entries, or via any operation that triggers conversion), zslInsertNode() asserts the score is not NAN (t_zset.c:260) and the server aborts. Any client with RESTORE access can remotely crash the server.

The skiplist RDB format (RDB_TYPE_ZSET / RDB_TYPE_ZSET_2) already rejects NAN scores at load time (rdb.c, "Zset with NAN score detected"). The listpack format (RDB_TYPE_ZSET_LISTPACK) had no equivalent check.

Reproduction

RESTORE k 0 "\x11\x19\x19\x00\x00\x00\x04\x00\x82m1\x03\x83nan\x04\x82m2\x03\x832.5\x04\xFF\x50\x00...."
# loads OK, then:
ZADD k 9 x      # forces listpack->skiplist conversion -> serverAssert(!isnan(node->score)) -> SIGABRT

Fix

Add zzlValidateScores(), which scans the scores of a listpack zset after structural validation and rejects the payload if any score is NAN. Mirrors the existing skiplist-format check. inf/-inf and large finite scores remain accepted (only NAN is rejected), matching normal ZADD semantics.

Testing

tests/integration/corrupt-dump.tcl: a RESTORE-path test asserting rejection and that the server stays up.
Verified the test fails on the pre-fix code (server crashes on conversion) and passes after the fix, by stashing the fix during the run.
Confirmed valid zsets, including inf/-inf/large finite scores, still load and convert correctly.
Full integration/corrupt-dump suite: 74 passed, 0 failed.

Note

Found via structure-aware fuzzing of the RESTORE path. This issue was generated by AI but verified, with love, by a human.

coderabbitai · 2026-06-05T03:46:19Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: bf18d88f-cc33-48ee-9a15-3bbdefdd1413

📥 Commits

Reviewing files that changed from the base of the PR and between c029b94 and c0730d5.

📒 Files selected for processing (4)

src/rdb.c
src/server.h
src/t_zset.c
tests/integration/corrupt-dump.tcl

🚧 Files skipped from review as they are similar to previous changes (2)

src/server.h
src/t_zset.c

📝 Walkthrough

Walkthrough

Adds zzlValidateScores() to detect NaN scores in listpack-encoded ZSETs, calls it during RDB load for both listpack and converted ziplist ZSETs to reject corrupt payloads, and adds tests that verify restores fail with appropriate logging while the server stays responsive.

Changes

NAN Score Validation for Listpack ZSETs

Layer / File(s)	Summary
Validation function definition `src/server.h`, `src/t_zset.c`	`zzlValidateScores()` iterates listpack member/score pairs and returns failure on odd element counts or NaN scores.
RDB loading validation checkpoint `src/rdb.c`	After ziplist→listpack conversion and for `RDB_TYPE_ZSET_LISTPACK`, loading calls `zzlValidateScores()`; failures log corruption, free payloads, clear the object, decrement refcount, and abort load.
Integration tests `tests/integration/corrupt-dump.tcl`	Adds tests that restoring crafted listpack and legacy ziplist ZSET payloads with NaN scores fails with "Bad data format", logs "NAN score", and server still responds to `PING`.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 75.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: adding validation to reject NAN scores in listpack/ziplist-encoded sorted sets during RDB load, which is the core fix in this pull request.
Description check	✅ Passed	The description comprehensively explains the problem (NAN score vulnerability in listpack ZSETs), the impact (remote crash via RESTORE), the fix (zzlValidateScores function), and testing approach, all directly related to the changeset.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 Infer (1.2.0)

src/rdb.c

src/rdb.c:40:10: fatal error: 'fpconv_dtoa.h' file not found
40 | #include "fpconv_dtoa.h"
| ^~~~~~~~~~~~~~~
1 error generated.
Error: the following clang command did not run successfully:
/opt/infer-linux-x86_64-v1.2.0/lib/infer/facebook-clang-plugins/clang/install/bin/clang-18
@/tmp/coderabbit-infer/c0730d56c90857254a6f05ad97c7ba4a7a954753-c77a3d2b15213159/tmp/clang_command_.tmp.d5a8bc.txt
++Contents of '/tmp/coderabbit-infer/c0730d56c90857254a6f05ad97c7ba4a7a954753-c77a3d2b15213159/tmp/clang_command_.tmp.d5a8bc.txt':
"-cc1" "-load"
"/opt/infer-linux-x86_64-v1.2.0/lib/infer/infer/bin/../../facebook-clang-plugins/libtooling/build/FacebookClangPlugin.dylib"
"-add-plugin" "BiniouASTExporter" "-plugin-arg-BiniouASTExporter" "-"
"-plugin-arg-BiniouASTExporter" "PREPEND_CURRENT_DIR=1"
"-plugin-arg-BiniouASTExporter" "MAX_STRING_SIZE=65535" "-cc1" "-triple"
"x86_64-unknown-linux-gnu" "-emit-obj" "-mrelax-all" "-disable-free"
"-clear-as

... [truncated 664 characters] ...

em"
"/opt/infer-linux-x86_64-v1.2.0/lib/infer/facebook-clang-plugins/clang/install/lib/clang/18/include"
"-internal-isystem" "/usr/local/include" "-internal-isystem"
"/usr/lib/gcc/x86_64-linux-gnu/12/../../../../x86_64-linux-gnu/include"
"-internal-externc-isystem" "/usr/include/x86_64-linux-gnu"
"-internal-externc-isystem" "/include" "-internal-externc-isystem"
"/usr/include" "-Wno-ignored-optimization-argument" "-Wno-everything"
"-ferror-limit" "19" "-fgnuc-version=4.2.1" "-fskip-odr-check-in-gmf"
"-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-o"
"/tmp/coderabbit-infer/c77a3d2b15213159/file.o" "-x" "c" "src/rdb.c"
"-O0" "-fno-builtin" "-include"
"/opt/infer-linux-x86_64-v1.2.0/lib/infer/infer/bin/../lib/clang_wrappers/global_defines.h"
"-Wno-everything"

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

A crafted RESTORE payload can store a NAN score in a listpack- or ziplist-encoded sorted set. The integrity validation (lpValidateIntegrityAndDups / ziplistPairsConvertAndValidateIntegrity) only checks the structure and member uniqueness, not score validity, so the payload is accepted on load. When the sorted set is later converted to a skiplist (for example when it grows past zset-max-listpack-entries, or via any operation that triggers conversion), zslInsertNode() asserts the score is not NAN and the server aborts. This is a remotely triggerable crash for any client with RESTORE access. The skiplist RDB format (RDB_TYPE_ZSET / RDB_TYPE_ZSET_2) already rejects NAN scores at load time. Add the equivalent check for the listpack format (RDB_TYPE_ZSET_LISTPACK) and the legacy ziplist format (RDB_TYPE_ZSET_ZIPLIST, which is converted to a listpack on load) via zzlValidateScores(). Add corrupt-dump integration tests covering both formats through the RESTORE path. Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>

github-actions · 2026-06-05T04:08:01Z

❌ Provenance Check Alert

Potential code similarities detected with upstream repository.

2026-06-05 04:08:01 [INFO] - matches redis/redis PR #9633 (similarity: 0.915, method: file_simhash+deep); file pairs: tests/integration/corrupt-dump.tcl <- tests/integration/corrupt-dump.tcl
2026-06-05 04:08:01 [INFO] - matches redis/redis PR #15251 (similarity: 0.915, method: file_simhash+deep); file pairs: tests/integration/corrupt-dump.tcl <- tests/integration/corrupt-dump.tcl

This check was performed automatically by the Provenance Guard Action.

codecov · 2026-06-05T04:34:01Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.65%. Comparing base (c8c38e7) to head (c0730d5).

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #3921      +/-   ##
============================================
+ Coverage     76.63%   76.65%   +0.01%     
============================================
  Files           162      162              
  Lines         80735    80755      +20     
============================================
+ Hits          61875    61902      +27     
+ Misses        18860    18853       -7

Files with missing lines	Coverage Δ
src/rdb.c	`76.98% <100.00%> (+0.04%)`	⬆️
src/server.h	`100.00% <ø> (ø)`
src/t_zset.c	`96.95% <100.00%> (+0.09%)`	⬆️

... and 15 files with indirect coverage changes

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

…#3921) ## Problem A crafted `RESTORE` payload can store a `NAN` score in a listpack-encoded sorted set. The integrity validation (`lpValidateIntegrityAndDups`) only checks the listpack *structure* and member uniqueness — it does not check score validity — so the payload is accepted on load. When the sorted set is later converted to a skiplist (e.g. when it grows past `zset-max-listpack-entries`, or via any operation that triggers conversion), `zslInsertNode()` asserts the score is not `NAN` (`t_zset.c:260`) and the server aborts. **Any client with `RESTORE` access can remotely crash the server.** The skiplist RDB format (`RDB_TYPE_ZSET` / `RDB_TYPE_ZSET_2`) already rejects `NAN` scores at load time (`rdb.c`, "Zset with NAN score detected"). The listpack format (`RDB_TYPE_ZSET_LISTPACK`) had no equivalent check. ## Reproduction ``` RESTORE k 0 "\x11\x19\x19\x00\x00\x00\x04\x00\x82m1\x03\x83nan\x04\x82m2\x03\x832.5\x04\xFF\x50\x00...." # loads OK, then: ZADD k 9 x # forces listpack->skiplist conversion -> serverAssert(!isnan(node->score)) -> SIGABRT ``` ## Fix Add `zzlValidateScores()`, which scans the scores of a listpack zset after structural validation and rejects the payload if any score is `NAN`. Mirrors the existing skiplist-format check. `inf`/`-inf` and large finite scores remain accepted (only `NAN` is rejected), matching normal `ZADD` semantics. ## Testing - `tests/integration/corrupt-dump.tcl`: a `RESTORE`-path test asserting rejection and that the server stays up. - Verified the test **fails on the pre-fix code** (server crashes on conversion) and **passes after the fix**, by stashing the fix during the run. - Confirmed valid zsets, including `inf`/`-inf`/large finite scores, still load and convert correctly. - Full `integration/corrupt-dump` suite: 74 passed, 0 failed. > [!NOTE] > Found via structure-aware fuzzing of the RESTORE path. This issue was generated by AI but verified, with love, by a human. Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>

…#3921) A crafted `RESTORE` payload can store a `NAN` score in a listpack-encoded sorted set. The integrity validation (`lpValidateIntegrityAndDups`) only checks the listpack *structure* and member uniqueness — it does not check score validity — so the payload is accepted on load. When the sorted set is later converted to a skiplist (e.g. when it grows past `zset-max-listpack-entries`, or via any operation that triggers conversion), `zslInsertNode()` asserts the score is not `NAN` (`t_zset.c:260`) and the server aborts. **Any client with `RESTORE` access can remotely crash the server.** The skiplist RDB format (`RDB_TYPE_ZSET` / `RDB_TYPE_ZSET_2`) already rejects `NAN` scores at load time (`rdb.c`, "Zset with NAN score detected"). The listpack format (`RDB_TYPE_ZSET_LISTPACK`) had no equivalent check. ``` RESTORE k 0 "\x11\x19\x19\x00\x00\x00\x04\x00\x82m1\x03\x83nan\x04\x82m2\x03\x832.5\x04\xFF\x50\x00...." ZADD k 9 x # forces listpack->skiplist conversion -> serverAssert(!isnan(node->score)) -> SIGABRT ``` Add `zzlValidateScores()`, which scans the scores of a listpack zset after structural validation and rejects the payload if any score is `NAN`. Mirrors the existing skiplist-format check. `inf`/`-inf` and large finite scores remain accepted (only `NAN` is rejected), matching normal `ZADD` semantics. - `tests/integration/corrupt-dump.tcl`: a `RESTORE`-path test asserting rejection and that the server stays up. - Verified the test **fails on the pre-fix code** (server crashes on conversion) and **passes after the fix**, by stashing the fix during the run. - Confirmed valid zsets, including `inf`/`-inf`/large finite scores, still load and convert correctly. - Full `integration/corrupt-dump` suite: 74 passed, 0 failed. > [!NOTE] > Found via structure-aware fuzzing of the RESTORE path. This issue was generated by AI but verified, with love, by a human. Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>

…#3921) ## Problem A crafted `RESTORE` payload can store a `NAN` score in a listpack-encoded sorted set. The integrity validation (`lpValidateIntegrityAndDups`) only checks the listpack *structure* and member uniqueness — it does not check score validity — so the payload is accepted on load. When the sorted set is later converted to a skiplist (e.g. when it grows past `zset-max-listpack-entries`, or via any operation that triggers conversion), `zslInsertNode()` asserts the score is not `NAN` (`t_zset.c:260`) and the server aborts. **Any client with `RESTORE` access can remotely crash the server.** The skiplist RDB format (`RDB_TYPE_ZSET` / `RDB_TYPE_ZSET_2`) already rejects `NAN` scores at load time (`rdb.c`, "Zset with NAN score detected"). The listpack format (`RDB_TYPE_ZSET_LISTPACK`) had no equivalent check. ## Reproduction ``` RESTORE k 0 "\x11\x19\x19\x00\x00\x00\x04\x00\x82m1\x03\x83nan\x04\x82m2\x03\x832.5\x04\xFF\x50\x00...." # loads OK, then: ZADD k 9 x # forces listpack->skiplist conversion -> serverAssert(!isnan(node->score)) -> SIGABRT ``` ## Fix Add `zzlValidateScores()`, which scans the scores of a listpack zset after structural validation and rejects the payload if any score is `NAN`. Mirrors the existing skiplist-format check. `inf`/`-inf` and large finite scores remain accepted (only `NAN` is rejected), matching normal `ZADD` semantics. ## Testing - `tests/integration/corrupt-dump.tcl`: a `RESTORE`-path test asserting rejection and that the server stays up. - Verified the test **fails on the pre-fix code** (server crashes on conversion) and **passes after the fix**, by stashing the fix during the run. - Confirmed valid zsets, including `inf`/`-inf`/large finite scores, still load and convert correctly. - Full `integration/corrupt-dump` suite: 74 passed, 0 failed. > [!NOTE] > Found via structure-aware fuzzing of the RESTORE path. This issue was generated by AI but verified, with love, by a human. Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>

…#3921) A crafted `RESTORE` payload can store a `NAN` score in a listpack-encoded sorted set. The integrity validation (`lpValidateIntegrityAndDups`) only checks the listpack *structure* and member uniqueness — it does not check score validity — so the payload is accepted on load. When the sorted set is later converted to a skiplist (e.g. when it grows past `zset-max-listpack-entries`, or via any operation that triggers conversion), `zslInsertNode()` asserts the score is not `NAN` (`t_zset.c:260`) and the server aborts. **Any client with `RESTORE` access can remotely crash the server.** The skiplist RDB format (`RDB_TYPE_ZSET` / `RDB_TYPE_ZSET_2`) already rejects `NAN` scores at load time (`rdb.c`, "Zset with NAN score detected"). The listpack format (`RDB_TYPE_ZSET_LISTPACK`) had no equivalent check. ``` RESTORE k 0 "\x11\x19\x19\x00\x00\x00\x04\x00\x82m1\x03\x83nan\x04\x82m2\x03\x832.5\x04\xFF\x50\x00...." ZADD k 9 x # forces listpack->skiplist conversion -> serverAssert(!isnan(node->score)) -> SIGABRT ``` Add `zzlValidateScores()`, which scans the scores of a listpack zset after structural validation and rejects the payload if any score is `NAN`. Mirrors the existing skiplist-format check. `inf`/`-inf` and large finite scores remain accepted (only `NAN` is rejected), matching normal `ZADD` semantics. - `tests/integration/corrupt-dump.tcl`: a `RESTORE`-path test asserting rejection and that the server stays up. - Verified the test **fails on the pre-fix code** (server crashes on conversion) and **passes after the fix**, by stashing the fix during the run. - Confirmed valid zsets, including `inf`/`-inf`/large finite scores, still load and convert correctly. - Full `integration/corrupt-dump` suite: 74 passed, 0 failed. > [!NOTE] > Found via structure-aware fuzzing of the RESTORE path. This issue was generated by AI but verified, with love, by a human. Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>

…#3921) ## Problem A crafted `RESTORE` payload can store a `NAN` score in a listpack-encoded sorted set. The integrity validation (`lpValidateIntegrityAndDups`) only checks the listpack *structure* and member uniqueness — it does not check score validity — so the payload is accepted on load. When the sorted set is later converted to a skiplist (e.g. when it grows past `zset-max-listpack-entries`, or via any operation that triggers conversion), `zslInsertNode()` asserts the score is not `NAN` (`t_zset.c:260`) and the server aborts. **Any client with `RESTORE` access can remotely crash the server.** The skiplist RDB format (`RDB_TYPE_ZSET` / `RDB_TYPE_ZSET_2`) already rejects `NAN` scores at load time (`rdb.c`, "Zset with NAN score detected"). The listpack format (`RDB_TYPE_ZSET_LISTPACK`) had no equivalent check. ## Reproduction ``` RESTORE k 0 "\x11\x19\x19\x00\x00\x00\x04\x00\x82m1\x03\x83nan\x04\x82m2\x03\x832.5\x04\xFF\x50\x00...." # loads OK, then: ZADD k 9 x # forces listpack->skiplist conversion -> serverAssert(!isnan(node->score)) -> SIGABRT ``` ## Fix Add `zzlValidateScores()`, which scans the scores of a listpack zset after structural validation and rejects the payload if any score is `NAN`. Mirrors the existing skiplist-format check. `inf`/`-inf` and large finite scores remain accepted (only `NAN` is rejected), matching normal `ZADD` semantics. ## Testing - `tests/integration/corrupt-dump.tcl`: a `RESTORE`-path test asserting rejection and that the server stays up. - Verified the test **fails on the pre-fix code** (server crashes on conversion) and **passes after the fix**, by stashing the fix during the run. - Confirmed valid zsets, including `inf`/`-inf`/large finite scores, still load and convert correctly. - Full `integration/corrupt-dump` suite: 74 passed, 0 failed. > [!NOTE] > Found via structure-aware fuzzing of the RESTORE path. This issue was generated by AI but verified, with love, by a human. Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>

…valkey-io#3921) (#308) ## Problem A crafted `RESTORE` payload can store a `NAN` score in a listpack-encoded sorted set. The integrity validation (`lpValidateIntegrityAndDups`) only checks the listpack *structure* and member uniqueness — it does not check score validity — so the payload is accepted on load. When the sorted set is later converted to a skiplist (e.g. when it grows past `zset-max-listpack-entries`, or via any operation that triggers conversion), `zslInsertNode()` asserts the score is not `NAN` (`t_zset.c:260`) and the server aborts. **Any client with `RESTORE` access can remotely crash the server.** The skiplist RDB format (`RDB_TYPE_ZSET` / `RDB_TYPE_ZSET_2`) already rejects `NAN` scores at load time (`rdb.c`, "Zset with NAN score detected"). The listpack format (`RDB_TYPE_ZSET_LISTPACK`) had no equivalent check. ## Reproduction ``` RESTORE k 0 "\x11\x19\x19\x00\x00\x00\x04\x00\x82m1\x03\x83nan\x04\x82m2\x03\x832.5\x04\xFF\x50\x00...." # loads OK, then: ZADD k 9 x # forces listpack->skiplist conversion -> serverAssert(!isnan(node->score)) -> SIGABRT ``` ## Fix Add `zzlValidateScores()`, which scans the scores of a listpack zset after structural validation and rejects the payload if any score is `NAN`. Mirrors the existing skiplist-format check. `inf`/`-inf` and large finite scores remain accepted (only `NAN` is rejected), matching normal `ZADD` semantics. ## Testing - `tests/integration/corrupt-dump.tcl`: a `RESTORE`-path test asserting rejection and that the server stays up. - Verified the test **fails on the pre-fix code** (server crashes on conversion) and **passes after the fix**, by stashing the fix during the run. - Confirmed valid zsets, including `inf`/`-inf`/large finite scores, still load and convert correctly. - Full `integration/corrupt-dump` suite: 74 passed, 0 failed. > [!NOTE] > Found via structure-aware fuzzing of the RESTORE path. This issue was generated by AI but verified, with love, by a human. (cherry picked from commit 98005d1) Signed-off-by: Madelyn Olson <madelyneolson@gmail.com> Co-authored-by: Madelyn Olson <madelyneolson@gmail.com>

…#3921) ## Problem A crafted `RESTORE` payload can store a `NAN` score in a listpack-encoded sorted set. The integrity validation (`lpValidateIntegrityAndDups`) only checks the listpack *structure* and member uniqueness — it does not check score validity — so the payload is accepted on load. When the sorted set is later converted to a skiplist (e.g. when it grows past `zset-max-listpack-entries`, or via any operation that triggers conversion), `zslInsertNode()` asserts the score is not `NAN` (`t_zset.c:260`) and the server aborts. **Any client with `RESTORE` access can remotely crash the server.** The skiplist RDB format (`RDB_TYPE_ZSET` / `RDB_TYPE_ZSET_2`) already rejects `NAN` scores at load time (`rdb.c`, "Zset with NAN score detected"). The listpack format (`RDB_TYPE_ZSET_LISTPACK`) had no equivalent check. ## Reproduction ``` RESTORE k 0 "\x11\x19\x19\x00\x00\x00\x04\x00\x82m1\x03\x83nan\x04\x82m2\x03\x832.5\x04\xFF\x50\x00...." # loads OK, then: ZADD k 9 x # forces listpack->skiplist conversion -> serverAssert(!isnan(node->score)) -> SIGABRT ``` ## Fix Add `zzlValidateScores()`, which scans the scores of a listpack zset after structural validation and rejects the payload if any score is `NAN`. Mirrors the existing skiplist-format check. `inf`/`-inf` and large finite scores remain accepted (only `NAN` is rejected), matching normal `ZADD` semantics. ## Testing - `tests/integration/corrupt-dump.tcl`: a `RESTORE`-path test asserting rejection and that the server stays up. - Verified the test **fails on the pre-fix code** (server crashes on conversion) and **passes after the fix**, by stashing the fix during the run. - Confirmed valid zsets, including `inf`/`-inf`/large finite scores, still load and convert correctly. - Full `integration/corrupt-dump` suite: 74 passed, 0 failed. > [!NOTE] > Found via structure-aware fuzzing of the RESTORE path. This issue was generated by AI but verified, with love, by a human. Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>

github-actions Bot assigned madolson Jun 5, 2026

madolson force-pushed the fix-zset-listpack-nan-score branch from c029b94 to c0730d5 Compare June 5, 2026 04:07

madolson changed the title ~~Reject NAN scores in listpack-encoded sorted sets on RDB load~~ Reject NAN scores in listpack/ziplist-encoded sorted sets on RDB load Jun 5, 2026

madolson requested review from enjoy-binbin and murphyjacob4 June 5, 2026 04:35

enjoy-binbin approved these changes Jun 5, 2026

View reviewed changes

madolson added this to Valkey 9.1, Valkey 9.0, Valkey 8.1, Valkey 8.0 and Valkey 7.2 Jun 5, 2026

murphyjacob4 approved these changes Jun 5, 2026

View reviewed changes

zuiderkwast approved these changes Jun 5, 2026

View reviewed changes

madolson merged commit 98005d1 into valkey-io:unstable Jun 11, 2026
61 of 63 checks passed

github-project-automation Bot moved this to To be backported in Valkey 7.2 Jun 11, 2026

github-project-automation Bot moved this to To be backported in Valkey 9.1 Jun 11, 2026

github-project-automation Bot moved this to To be backported in Valkey 8.1 Jun 11, 2026

github-project-automation Bot moved this to To be backported in Valkey 8.0 Jun 11, 2026

github-project-automation Bot moved this to To be backported in Valkey 9.0 Jun 11, 2026

valkeyrie-ops Bot mentioned this pull request Jun 9, 2026

[backport] Backport sweep for 8.1 #3917

Open

valkeyrie-ops Bot mentioned this pull request Jun 9, 2026

[backport] Backport sweep for 7.2 #3738

Merged

valkeyrie-ops Bot mentioned this pull request Jun 9, 2026

[backport] Backport sweep for 8.0 #3736

Merged

valkeyrie-ops Bot mentioned this pull request Jun 12, 2026

[backport] Backport sweep for 9.1 #3970

Closed

This was referenced Jun 15, 2026

Fix NAN-score listpack test payload for the 8.0 RDB version #3988

Closed

Fix NAN-score listpack test payload for the 7.2 RDB version #3989

Closed

valkeyrie-ops Bot mentioned this pull request Jun 15, 2026

[backport] Backport sweep for 9.1 #3987

Open

valkeyrie-ops Bot moved this from To be backported to Done in Valkey 7.2 Jun 17, 2026

sarthakaggarwal97 mentioned this pull request Jun 18, 2026

[Test] NAN-score listpack backport (ci_fix dry-run) sarthakaggarwal97/valkey#294

Closed

valkeyrie-ops Bot moved this from To be backported to Done in Valkey 8.0 Jun 18, 2026

valkeyrie-ops Bot mentioned this pull request Jun 24, 2026

[backport] Backport sweep for 9.0 #3879

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Reject NAN scores in listpack/ziplist-encoded sorted sets on RDB load#3921

Reject NAN scores in listpack/ziplist-encoded sorted sets on RDB load#3921
madolson merged 1 commit into
valkey-io:unstablefrom
madolson:fix-zset-listpack-nan-score

madolson commented Jun 5, 2026

Uh oh!

coderabbitai Bot commented Jun 5, 2026 •

edited

Loading

Walkthrough

Changes

Estimated code review effort

❌ Failed checks (1 warning)

Uh oh!

github-actions Bot commented Jun 5, 2026

Uh oh!

codecov Bot commented Jun 5, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

madolson commented Jun 5, 2026

Problem

Reproduction

Fix

Testing

Uh oh!

coderabbitai Bot commented Jun 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Estimated code review effort

❌ Failed checks (1 warning)

Uh oh!

github-actions Bot commented Jun 5, 2026

❌ Provenance Check Alert

Uh oh!

codecov Bot commented Jun 5, 2026

Codecov Report

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

coderabbitai Bot commented Jun 5, 2026 •

edited

Loading