fix(hash): Untrack hash with volatile fields when it is overwritten by frostzt · Pull Request #3003 · valkey-io/valkey

frostzt · 2026-01-04T15:17:16Z

In dbSetValue if the robj is a hash with volatile fields we need to clean it up. It causes two core problems:

Type Confusion: Allows converting from hash to string with keys_with_volatile_items tracked
Tracked Items with dangling pointer: Converting from hash to ie. a string breaks this as keys_with_volatile_items is not cleaned up.

Check #3000

Signed-off-by: frostzt <aidenfrostbite@gmail.com>

frostzt · 2026-01-04T15:30:50Z

Ain't gonna lie I am not sure about this test here! Is this related to this or is this something else?

codecov · 2026-01-04T15:37:27Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 74.02%. Comparing base (50667e0) to head (da8d612).
⚠️ Report is 5 commits behind head on unstable.

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #3003      +/-   ##
============================================
- Coverage     74.29%   74.02%   -0.27%     
============================================
  Files           129      129              
  Lines         70895    70899       +4     
============================================
- Hits          52670    52485     -185     
- Misses        18225    18414     +189

Files with missing lines	Coverage Δ
src/db.c	`94.17% <100.00%> (+0.01%)`	⬆️

... and 25 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.

ranshid · 2026-01-04T15:54:29Z

Ain't gonna lie I am not sure about this test here! Is this related to this or is this something else?

not related to #3000. this is a "day 1" HFE bug

Signed-off-by: frostzt <aidenfrostbite@gmail.com>

dvkashapov

I'm not sure initial suggestion is sufficient but I may be wrong. In case where both old and new are hashes with volatile fields, shouldn't pointer be updated if it changed?

dvkashapov · 2026-01-04T16:45:30Z

            serverAssert(expireref != NULL);
            *expireref = new;
        }
    }


@ranshid After this line, shouldn't we do something like this?

if (old_was_hash_with_volatile) { bool new_is_hash_with_volatile = (new->type == OBJ_HASH && hashTypeHasVolatileFields(new)); if (new_is_hash_with_volatile) { int dict_index = getKVStoreIndexForKey(key->ptr); hashtable *volatile_items_ht = kvstoreGetHashtable(db->keys_with_volatile_items, dict_index); hashtableReplaceReallocatedEntry(volatile_items_ht, old, new); } else { dbUntrackKeyWithVolatileItems(db, new); } } else { dbTrackKeyWithVolatileItems(db, new); }

where old_was_hash_with_volatile = (old->type == OBJ_HASH && hashTypeHasVolatileFields(old));

So theoretically if there is a case were someone will swap the content of a hash object with a different hash object I would say yes. the thing is, I do not think there is anyway this is currently done today.
The thing is that dbSetValue is called from setKey, dbAddInternal and dbReplaceValue
in all cases were the the old value was hash, it will be untracked (as we wanted).

The problem you mention is "what happen in case the new value is also a hash with volatile items?"
I think there is no case currently which allows that, but I would say that we can add a generic support for that by just calling

dbTrackKeyWithVolatileItems(db, new);

Signed-off-by: frostzt <aidenfrostbite@gmail.com>

ranshid · 2026-01-04T17:24:30Z

@frostzt lets take @dvkashapov advise and make the change instead like:

--- a/src/db.c
+++ b/src/db.c
@@ -370,6 +370,12 @@ static void dbSetValue(serverDb *db, robj *key, robj **valref, int overwrite, vo
             *expireref = new;
         }
     }
+    /* If overwriting a hash object, un-track it from the volatile items tracking if it contains volatile items.*/
+    if (old->type == OBJ_HASH && hashTypeHasVolatileFields(old)) {
+        dbUntrackKeyWithVolatileItems(db, old);
+    }
+    /* If the new object is a hash with volatile items we need to track it again */
+    dbTrackKeyWithVolatileItems(db, new);
     /* For efficiency, let the I/O thread that allocated an object also deallocate it. */
     if (tryOffloadFreeObjToIOThreads(old) == C_OK) {
         /* OK */

frostzt · 2026-01-04T17:32:37Z

@frostzt lets take @dvkashapov advise and make the change instead like:

--- a/src/db.c
+++ b/src/db.c
@@ -370,6 +370,12 @@ static void dbSetValue(serverDb *db, robj *key, robj **valref, int overwrite, vo
             *expireref = new;
         }
     }
+    /* If overwriting a hash object, un-track it from the volatile items tracking if it contains volatile items.*/
+    if (old->type == OBJ_HASH && hashTypeHasVolatileFields(old)) {
+        dbUntrackKeyWithVolatileItems(db, old);
+    }
+    /* If the new object is a hash with volatile items we need to track it again */
+    dbTrackKeyWithVolatileItems(db, new);
     /* For efficiency, let the I/O thread that allocated an object also deallocate it. */
     if (tryOffloadFreeObjToIOThreads(old) == C_OK) {
         /* OK */

@ranshid Awesome just so I get the idea right here, the dbUntrackKeyWithVolatileItems(db, old); handles the case we already know it untracks the volatile items associated with the old object. However the case we now account for is that the new object itself is a hash in this case we need to track the new object's keys instead? My question here is that you also mentioned "currently not possible", now i might be totally off here but just wanna sound dumb now rather be sorry later.

It means that when we do

HSETEX myhash EX 100 FIELDS 1 field1 value1

We can't really create myhash from scratch? With totally different values?

Signed-off-by: frostzt <aidenfrostbite@gmail.com>

frostzt · 2026-01-04T17:37:31Z

+            dbUntrackKeyWithVolatileItems(db, old);
+        }
+        /* If the new object is a hash with volatile items we need to track it again */
+        dbTrackKeyWithVolatileItems(db, new);


oh yeah we can't do this here its uninitialized here!

@ranshid should we move this dbTrackKeyWithVolatileItems inside the else...if (expiry... block?

no you should move this entire new section to line 379 (373 in the original implementation)

ranshid · 2026-01-04T17:45:46Z

@frostzt lets take @dvkashapov advise and make the change instead like:
--- a/src/db.c
+++ b/src/db.c
@@ -370,6 +370,12 @@ static void dbSetValue(serverDb *db, robj *key, robj **valref, int overwrite, vo
             *expireref = new;
         }
     }
+    /* If overwriting a hash object, un-track it from the volatile items tracking if it contains volatile items.*/
+    if (old->type == OBJ_HASH && hashTypeHasVolatileFields(old)) {
+        dbUntrackKeyWithVolatileItems(db, old);
+    }
+    /* If the new object is a hash with volatile items we need to track it again */
+    dbTrackKeyWithVolatileItems(db, new);
     /* For efficiency, let the I/O thread that allocated an object also deallocate it. */
     if (tryOffloadFreeObjToIOThreads(old) == C_OK) {
         /* OK */
@ranshid Awesome just so I get the idea right here, the dbUntrackKeyWithVolatileItems(db, old); handles the case we already know it untracks the volatile items associated with the old object. However the case we now account for is that the new object itself is a hash in this case we need to track the new object's keys instead? My question here is that you also mentioned "currently not possible", now i might be totally off here but just wanna sound dumb now rather be sorry later.

It means that when we do
HSETEX myhash EX 100 FIELDS 1 field1 value1
We can't really create myhash from scratch? With totally different values?

I think there is no easy way you can currently test the case of "in-place replacing a hash with a different hash"
The only case that comes to mind is using the ValkeyModule_ModuleTypeSetValue and write some dedicated module test, But the problematic part is to create a hash object with VM_HashSet since it will also crerate this object in the generic dictionary. You can then try to use the same object in order to replace another object that was initially created with volatile elements. IMO this is too complex once we made the code to work this way.

Signed-off-by: frostzt <aidenfrostbite@gmail.com>

ranshid · 2026-01-04T17:59:00Z

+        /* If overwriting a hash object, un-track it from the volatile items tracking if it contains volatile items.*/
+        if (old->type == OBJ_HASH && hashTypeHasVolatileFields(old)) {
+            dbUntrackKeyWithVolatileItems(db, old);
+        }


this section should be moved before the section you added in line 378

ok now it makes total sense to me, actually when we put this part inside the overwrite I was a little confused as the comment above says that its only when we perform edits!

Signed-off-by: frostzt <aidenfrostbite@gmail.com>

ranshid

Perfect! Thank you @frostzt and @dvkashapov !

frostzt · 2026-01-04T18:06:08Z

Perfect! Thank you @frostzt and @dvkashapov !

Thanks a lot @ranshid honestly I am more surprised by how much you know this thing internally! Please feel free to mention me to issues or (if you think) features that you feel I can pick up! I am more than eager to contribute to Valkey 😃

Hopefully I can clear our your backlogs maybe 🤣

In `dbSetValue()` the `old` pointer may be reassigned to point to the incoming value object which was created without an embedded key, so calling `dbUntrackKeyWithVolatileItems()` would call `objectGetKey()` which returns NULL, causing a crash in `hashtableSdsHash()` when trying to hash the NULL key. Idea is to assign `old_was_hash_with_volatile` before the swap and use `new` instead of `old` for untracking when theres no embedded key. Introduced in #3003 Run with NULL ptr dereference: https://github.com/valkey-io/valkey/actions/runs/20701343184/job/59424029880 --------- Signed-off-by: Daniil Kashapov <daniil.kashapov.ykt@gmail.com> Co-authored-by: Ran Shidlansik <ranshid@amazon.com>

…alkey-io#3003) In `dbSetValue` if the robj is a hash with volatile fields we need to clean it up. It causes two core problems: 1. Type Confusion: Allows converting from hash to string with `keys_with_volatile_items` tracked 2. Tracked Items with dangling pointer: Converting from `hash` to ie. a string breaks this as `keys_with_volatile_items` is not cleaned up. Check valkey-io#3000 --------- Signed-off-by: frostzt <aidenfrostbite@gmail.com>

In `dbSetValue()` the `old` pointer may be reassigned to point to the incoming value object which was created without an embedded key, so calling `dbUntrackKeyWithVolatileItems()` would call `objectGetKey()` which returns NULL, causing a crash in `hashtableSdsHash()` when trying to hash the NULL key. Idea is to assign `old_was_hash_with_volatile` before the swap and use `new` instead of `old` for untracking when theres no embedded key. Introduced in valkey-io#3003 Run with NULL ptr dereference: https://github.com/valkey-io/valkey/actions/runs/20701343184/job/59424029880 --------- Signed-off-by: Daniil Kashapov <daniil.kashapov.ykt@gmail.com> Co-authored-by: Ran Shidlansik <ranshid@amazon.com>

…alkey-io#3003) In `dbSetValue` if the robj is a hash with volatile fields we need to clean it up. It causes two core problems: 1. Type Confusion: Allows converting from hash to string with `keys_with_volatile_items` tracked 2. Tracked Items with dangling pointer: Converting from `hash` to ie. a string breaks this as `keys_with_volatile_items` is not cleaned up. Check valkey-io#3000 --------- Signed-off-by: frostzt <aidenfrostbite@gmail.com>

In `dbSetValue()` the `old` pointer may be reassigned to point to the incoming value object which was created without an embedded key, so calling `dbUntrackKeyWithVolatileItems()` would call `objectGetKey()` which returns NULL, causing a crash in `hashtableSdsHash()` when trying to hash the NULL key. Idea is to assign `old_was_hash_with_volatile` before the swap and use `new` instead of `old` for untracking when theres no embedded key. Introduced in valkey-io#3003 Run with NULL ptr dereference: https://github.com/valkey-io/valkey/actions/runs/20701343184/job/59424029880 --------- Signed-off-by: Daniil Kashapov <daniil.kashapov.ykt@gmail.com> Co-authored-by: Ran Shidlansik <ranshid@amazon.com>

…alkey-io#3003) In `dbSetValue` if the robj is a hash with volatile fields we need to clean it up. It causes two core problems: 1. Type Confusion: Allows converting from hash to string with `keys_with_volatile_items` tracked 2. Tracked Items with dangling pointer: Converting from `hash` to ie. a string breaks this as `keys_with_volatile_items` is not cleaned up. Check valkey-io#3000 --------- Signed-off-by: frostzt <aidenfrostbite@gmail.com> Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

In `dbSetValue()` the `old` pointer may be reassigned to point to the incoming value object which was created without an embedded key, so calling `dbUntrackKeyWithVolatileItems()` would call `objectGetKey()` which returns NULL, causing a crash in `hashtableSdsHash()` when trying to hash the NULL key. Idea is to assign `old_was_hash_with_volatile` before the swap and use `new` instead of `old` for untracking when theres no embedded key. Introduced in valkey-io#3003 Run with NULL ptr dereference: https://github.com/valkey-io/valkey/actions/runs/20701343184/job/59424029880 --------- Signed-off-by: Daniil Kashapov <daniil.kashapov.ykt@gmail.com> Co-authored-by: Ran Shidlansik <ranshid@amazon.com> Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

…alkey-io#3003) In `dbSetValue` if the robj is a hash with volatile fields we need to clean it up. It causes two core problems: 1. Type Confusion: Allows converting from hash to string with `keys_with_volatile_items` tracked 2. Tracked Items with dangling pointer: Converting from `hash` to ie. a string breaks this as `keys_with_volatile_items` is not cleaned up. Check valkey-io#3000 --------- Signed-off-by: frostzt <aidenfrostbite@gmail.com>

In `dbSetValue()` the `old` pointer may be reassigned to point to the incoming value object which was created without an embedded key, so calling `dbUntrackKeyWithVolatileItems()` would call `objectGetKey()` which returns NULL, causing a crash in `hashtableSdsHash()` when trying to hash the NULL key. Idea is to assign `old_was_hash_with_volatile` before the swap and use `new` instead of `old` for untracking when theres no embedded key. Introduced in valkey-io#3003 Run with NULL ptr dereference: https://github.com/valkey-io/valkey/actions/runs/20701343184/job/59424029880 --------- Signed-off-by: Daniil Kashapov <daniil.kashapov.ykt@gmail.com> Co-authored-by: Ran Shidlansik <ranshid@amazon.com>

…alkey-io#3003) In `dbSetValue` if the robj is a hash with volatile fields we need to clean it up. It causes two core problems: 1. Type Confusion: Allows converting from hash to string with `keys_with_volatile_items` tracked 2. Tracked Items with dangling pointer: Converting from `hash` to ie. a string breaks this as `keys_with_volatile_items` is not cleaned up. Check valkey-io#3000 --------- Signed-off-by: frostzt <aidenfrostbite@gmail.com> Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

In `dbSetValue()` the `old` pointer may be reassigned to point to the incoming value object which was created without an embedded key, so calling `dbUntrackKeyWithVolatileItems()` would call `objectGetKey()` which returns NULL, causing a crash in `hashtableSdsHash()` when trying to hash the NULL key. Idea is to assign `old_was_hash_with_volatile` before the swap and use `new` instead of `old` for untracking when theres no embedded key. Introduced in valkey-io#3003 Run with NULL ptr dereference: https://github.com/valkey-io/valkey/actions/runs/20701343184/job/59424029880 --------- Signed-off-by: Daniil Kashapov <daniil.kashapov.ykt@gmail.com> Co-authored-by: Ran Shidlansik <ranshid@amazon.com> Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

…3003) In `dbSetValue` if the robj is a hash with volatile fields we need to clean it up. It causes two core problems: 1. Type Confusion: Allows converting from hash to string with `keys_with_volatile_items` tracked 2. Tracked Items with dangling pointer: Converting from `hash` to ie. a string breaks this as `keys_with_volatile_items` is not cleaned up. Check #3000 --------- Signed-off-by: frostzt <aidenfrostbite@gmail.com> Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

In `dbSetValue()` the `old` pointer may be reassigned to point to the incoming value object which was created without an embedded key, so calling `dbUntrackKeyWithVolatileItems()` would call `objectGetKey()` which returns NULL, causing a crash in `hashtableSdsHash()` when trying to hash the NULL key. Idea is to assign `old_was_hash_with_volatile` before the swap and use `new` instead of `old` for untracking when theres no embedded key. Introduced in #3003 Run with NULL ptr dereference: https://github.com/valkey-io/valkey/actions/runs/20701343184/job/59424029880 --------- Signed-off-by: Daniil Kashapov <daniil.kashapov.ykt@gmail.com> Co-authored-by: Ran Shidlansik <ranshid@amazon.com> Signed-off-by: Ran Shidlansik <ranshid@amazon.com>

…alkey-io#3003) In `dbSetValue` if the robj is a hash with volatile fields we need to clean it up. It causes two core problems: 1. Type Confusion: Allows converting from hash to string with `keys_with_volatile_items` tracked 2. Tracked Items with dangling pointer: Converting from `hash` to ie. a string breaks this as `keys_with_volatile_items` is not cleaned up. Check valkey-io#3000 --------- Signed-off-by: frostzt <aidenfrostbite@gmail.com> Signed-off-by: Harkrishn Patro <bunty.hari@gmail.com>

In `dbSetValue()` the `old` pointer may be reassigned to point to the incoming value object which was created without an embedded key, so calling `dbUntrackKeyWithVolatileItems()` would call `objectGetKey()` which returns NULL, causing a crash in `hashtableSdsHash()` when trying to hash the NULL key. Idea is to assign `old_was_hash_with_volatile` before the swap and use `new` instead of `old` for untracking when theres no embedded key. Introduced in valkey-io#3003 Run with NULL ptr dereference: https://github.com/valkey-io/valkey/actions/runs/20701343184/job/59424029880 --------- Signed-off-by: Daniil Kashapov <daniil.kashapov.ykt@gmail.com> Co-authored-by: Ran Shidlansik <ranshid@amazon.com> Signed-off-by: Harkrishn Patro <bunty.hari@gmail.com>

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [docker.io/valkey/valkey](https://github.com/valkey-io/valkey) | image | patch | `9.0.1` → `9.0.4` | --- ### Release Notes <details> <summary>valkey-io/valkey (docker.io/valkey/valkey)</summary> ### [`v9.0.4`](https://github.com/valkey-io/valkey/releases/tag/9.0.4) [Compare Source](valkey-io/valkey@9.0.3...9.0.4) Upgrade urgency SECURITY: This release includes security fixes we recommend you apply as soon as possible. ##### Security fixes - (CVE-2026-23479) Use-After-Free in unblock client flow - (CVE-2026-25243) Invalid Memory Access in RESTORE command - (CVE-2026-23631) Use-after-free when full sync occurs during a yielding Lua/function execution ### [`v9.0.3`](https://github.com/valkey-io/valkey/releases/tag/9.0.3) [Compare Source](valkey-io/valkey@9.0.2...9.0.3) ##### Valkey 9.0.3 Upgrade urgency SECURITY: This release includes security fixes we recommend you apply as soon as possible. ##### Security fixes - (CVE-2025-67733) RESP Protocol Injection via Lua error\_reply - (CVE-2026-21863) Remote DoS with malformed Valkey Cluster bus message - (CVE-2026-27623) Reset request type after handling empty requests ##### Bug fixes - Avoids crash during MODULE UNLOAD when ACL rules reference a module command and subcommand ([#3160](valkey-io/valkey#3160)) - Fix server assert on ACL LOAD when current user loses permission to channels ([#3182](valkey-io/valkey#3182)) - Fix bug causing no response flush sometimes when IO threads are busy ([#3205](valkey-io/valkey#3205)) ### [`v9.0.2`](https://github.com/valkey-io/valkey/releases/tag/9.0.2) [Compare Source](valkey-io/valkey@9.0.1...9.0.2) Upgrade urgency HIGH: There are critical bugs that may affect a subset of users. #### Bug fixes - Avoid memory leak of new argv when HEXPIRE commands target only non-exiting fields ([#2973](valkey-io/valkey#2973)) - Fix HINCRBY and HINCRBYFLOAT to update volatile key tracking ([#2974](valkey-io/valkey#2974)) - Avoid empty hash object when HSETEX added no fields ([#2998](valkey-io/valkey#2998)) - Fix case-sensitive check for the FNX and FXX arguments in HSETEX ([#3000](valkey-io/valkey#3000)) - Prevent assertion in active expiration job after a hash with volatile fields is overwritten ([#3003](valkey-io/valkey#3003), [#3007](valkey-io/valkey#3007)) - Fix HRANDFIELD to return null response when no field could be found ([#3022](valkey-io/valkey#3022)) - Fix HEXPIRE to not delete items when validation rules fail and expiration is in the past ([#3023](valkey-io/valkey#3023), [#3048](valkey-io/valkey#3048)) - Fix how hash is handling overriding of expired fields overwrite ([#3060](valkey-io/valkey#3060)) - HSETEX - Always issue keyspace notifications after validation ([#3001](valkey-io/valkey#3001)) - Make zero a valid TTL for hash fields during import mode and data loading ([#3006](valkey-io/valkey#3006)) - Trigger prepareCommand on argc change in module command filters ([#2945](valkey-io/valkey#2945)) - Restrict TTL from being negative and avoid crash in import-mode ([#2944](valkey-io/valkey#2944)) - Fix chained replica crash when doing dual channel replication ([#2983](valkey-io/valkey#2983)) - Skip slot cache optimization for AOF client to prevent key duplication and data corruption ([#3004](valkey-io/valkey#3004)) - Fix used\_memory\_dataset underflow due to miscalculated used\_memory\_overhead ([#3005](valkey-io/valkey#3005)) - Avoid duplicate calculations of network-bytes-out in slot stats with copy-avoidance ([#3046](valkey-io/valkey#3046)) - Fix XREAD returning error on empty stream with + ID ([#2742](valkey-io/valkey#2742)) #### Performance/Efficiency Improvements - Track reply bytes in I/O threads if commandlog-reply-larger-than is -1 ([#3086](valkey-io/valkey#3086), [#3126](valkey-io/valkey#3126)). This makes it possible to mitigate a performance regression in 9.0.1 caused by the bug fix [#2652](valkey-io/valkey#2652). **Full Changelog**: <valkey-io/valkey@9.0.1...9.0.2> </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - "before 6am" - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://github.com/renovatebot/renovate).

github-actions Bot assigned frostzt Jan 4, 2026

fix(hash): clean volatile fields if the oldobj is a hash

1ce65a8

Signed-off-by: frostzt <aidenfrostbite@gmail.com>

frostzt force-pushed the hash_untrack_volatile_items branch from 18d6f28 to 1ce65a8 Compare January 4, 2026 15:17

frostzt mentioned this pull request Jan 4, 2026

fix(HSETEX): replace strcmp with strcasecmp #3000

Merged

ranshid reviewed Jan 4, 2026

View reviewed changes

ranshid added this to Valkey 9.0 and Valkey 9.1 Jan 4, 2026

ranshid moved this to To be backported in Valkey 9.0 Jan 4, 2026

ranshid added bug Something isn't working release-notes This issue should get a line item in the release notes labels Jan 4, 2026

ranshid changed the title ~~fix(hash): clean volatile fields if the oldobj is a hash~~ fix(hash): Untrack hash with volatile fields when it is overwritten Jan 4, 2026

ranshid closed this Jan 4, 2026

github-project-automation Bot moved this from To be backported to Done in Valkey 9.0 Jan 4, 2026

github-project-automation Bot moved this to Done in Valkey 9.1 Jan 4, 2026

ranshid reopened this Jan 4, 2026

ranshid reviewed Jan 4, 2026

View reviewed changes

Comment thread tests/unit/type/hash.tcl Outdated

ranshid moved this from Done to To be backported in Valkey 9.0 Jan 4, 2026

ranshid moved this from Done to Todo in Valkey 9.1 Jan 4, 2026

chore: move tests to hashexpire.tcl

57a10a5

Signed-off-by: frostzt <aidenfrostbite@gmail.com>

dvkashapov reviewed Jan 4, 2026

View reviewed changes

ranshid reviewed Jan 4, 2026

View reviewed changes

Comment thread tests/unit/hashexpire.tcl Outdated

Comment thread tests/unit/hashexpire.tcl Outdated

chore: remove redundant tests

5f56f98

Signed-off-by: frostzt <aidenfrostbite@gmail.com>

feat: track volatile items if the new item is a hash

1813ee8

Signed-off-by: frostzt <aidenfrostbite@gmail.com>

frostzt commented Jan 4, 2026

View reviewed changes

chore: move dbTrackWithVolatileItems out

1d9a40e

Signed-off-by: frostzt <aidenfrostbite@gmail.com>

ranshid reviewed Jan 4, 2026

View reviewed changes

chore: check for volatile items in hash when setting keys

da8d612

Signed-off-by: frostzt <aidenfrostbite@gmail.com>

ranshid approved these changes Jan 4, 2026

View reviewed changes

ranshid merged commit e4a3e9f into valkey-io:unstable Jan 4, 2026
24 checks passed

github-project-automation Bot moved this from Todo to Done in Valkey 9.1 Jan 4, 2026

frostzt deleted the hash_untrack_volatile_items branch January 4, 2026 18:31

dvkashapov mentioned this pull request Jan 5, 2026

Untrack key based on old->hasembkey #3007

Merged

zuiderkwast moved this from To be backported to 9.0.2 WIP in Valkey 9.0 Jan 28, 2026

zuiderkwast mentioned this pull request Jan 28, 2026

Backport hfe fixes to 9.0 #3111

Merged

Uh oh!

Conversation

frostzt commented Jan 4, 2026

Uh oh!

frostzt commented Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov Bot commented Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ranshid commented Jan 4, 2026

Uh oh!

Uh oh!

dvkashapov left a comment

Choose a reason for hiding this comment

Uh oh!

dvkashapov Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

ranshid Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ranshid commented Jan 4, 2026

Uh oh!

frostzt commented Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

frostzt Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

frostzt Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

ranshid Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ranshid commented Jan 4, 2026

Uh oh!

ranshid Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

frostzt Jan 4, 2026

Choose a reason for hiding this comment

Uh oh!

ranshid left a comment

Choose a reason for hiding this comment

Uh oh!

frostzt commented Jan 4, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

frostzt commented Jan 4, 2026 •

edited

Loading

codecov Bot commented Jan 4, 2026 •

edited

Loading

ranshid Jan 4, 2026 •

edited

Loading

frostzt commented Jan 4, 2026 •

edited

Loading

ranshid Jan 4, 2026 •

edited

Loading