Adds HGETDEL Support to Valkey #2851

roshkhatri · 2025-11-17T08:28:56Z

Fixes this: #2850
Adds support for HGETDEL to Valkey and aligns with Redis 8.0 feature.
Maintains syntax compatibility
Retrieves all the values, and null if fields dont exists and deletes once retrieved.

127.0.0.1:6379> HGETDEL key FIELDS numfields field [ field ... ]

127.0.0.1:6379> HSET foo field1 bar1 field2 bar2 field3 bar3
(integer) 3
127.0.0.1:6379> HGETDEL foo FIELDS 1 field2
1) "bar2"
127.0.0.1:6379> HGETDEL foo FIELDS 1 field2
1) (nil)
127.0.0.1:6379> HGETALL foo
1) "field1"
2) "bar1"
3) "field3"
4) "bar3"
127.0.0.1:6379>  HGETDEL foo FIELDS 2 field2 field3
1) (nil)
2) "bar3"
127.0.0.1:6379> HGETALL foo
1) "field1"
2) "bar1"
127.0.0.1:6379> HGETDEL foo FIELDS 3 field1 non-exist-field
(error) ERR syntax error
127.0.0.1:6379> HGETDEL foo FIELDS 2 field1 non-exist-field
1) "bar1"
2) (nil)
127.0.0.1:6379> HGETALL foo
(empty array)
127.0.0.1:6379>

Signed-off-by: Roshan Khatri <[email protected]>

codecov · 2025-11-17T08:55:44Z

Codecov Report

❌ Patch coverage is 96.66667% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 72.43%. Comparing base (86db609) to head (658054d).
⚠️ Report is 3 commits behind head on unstable.

Files with missing lines	Patch %	Lines
src/t_hash.c	96.66%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #2851      +/-   ##
============================================
+ Coverage     72.26%   72.43%   +0.17%     
============================================
  Files           128      128              
  Lines         70370    70401      +31     
============================================
+ Hits          50851    50998     +147     
+ Misses        19519    19403     -116

Files with missing lines	Coverage Δ
src/commands.def	`100.00% <ø> (ø)`
src/server.h	`100.00% <ø> (ø)`
src/t_hash.c	`96.17% <96.66%> (-0.08%)`	⬇️

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

hwware · 2025-11-17T18:07:50Z

@valkey-io/core-team I would like to add this pr to next meeting agenda to discuss more, Thanks

hwware · 2025-11-17T18:09:35Z

I think it is one feature to align with Redis 8

zuiderkwast · 2025-11-17T18:54:12Z

If it's the same syntax as in Redis 8, I vote YES.

roshkhatri · 2025-11-17T19:04:46Z

If it's the same syntax as in Redis 8, I vote YES.

It is not, but I can make it the same

zuiderkwast · 2025-11-17T19:22:45Z

Ah... Redis insist on using this very ugly syntax for all new commands. It appears to be designed for machine generated command lines, not humans.

HGETDEL key FIELDS numfields field [field ...]

I think your syntax HGETDEL key field [field ...] is much nicer. I don't know if Redis compatibility is important or not. Maybe it's best to discuss it in a meeting then.

@valkey-io/client-maintainers WDYT?

roshkhatri · 2025-11-17T19:26:58Z

Yeah, it is the same as HTTL

HTTL key FIELDS numfields field [ field ... ]

https://valkey.io/commands/httl/

The one I implemented is similar to HMGET: HMGET key field [ field ... ]

I think we have similar syntax in valkey as well so it would be generally better to keep compatibility

JimB123 · 2025-11-17T19:41:18Z

I like consistency with HMGET better than creating a weird syntax just to align with Redis.

That said, IF the 3rd parameter is a number AND the number equals the number of remaining parameters, we could just silently ignore it. But, unfortunately, that becomes ambiguous in a case like this: HGETDEL key 3 4 5 6 - is "3" a field? or a count of fields?

hpatro

Regarding the syntax, users migrating from Redis to Valkey will have problems if we don't choose to stick with it. We have decided to stick through with so many of features so far (Hash field expiration / Search / JSON). So, I think we should continue have symmetry with them atleast on the data path commands which were introduced there first.

Signed-off-by: Roshan Khatri <[email protected]>

nihohit · 2025-11-17T20:07:23Z

Breaking API with Redis will mean that client maintainers might need to choose sides, and only fully support one DB, and offer partial support for the other, which will also lead to poor UX for the client users, since these details are easy to miss, and expectations won't match reality.
Unless there's a clear benefit that's worth the potential harm, I would prefer for valkey to be consistent with Redis where possible (and the other way around too, of course).

roshkhatri · 2025-11-17T20:12:34Z

Updated the top comment and this PR now maintain syntax compatibility.

hwware · 2025-11-17T20:32:19Z

I have one question: In Redis 8.0, it introduces this command HGETDEL, the open source license was changed before Redis 8.0. I am not sure how many users migrating from Redis 8.0 to Valkey? Do we need still align with the Redis weird syntax?

Honestly, I do not like the format: HGETDEL key FIELDS numfields field [field ...]

ranshid

Gave a quick one (and will continue tomorrow)
Looks good overall. I would be happy if we can also include a test in hashexpire.tcl to test the command when there are expired fields.

src/t_hash.c

ranshid · 2025-11-17T22:11:51Z

src/t_hash.c

+            dbUpdateObjectWithVolatileItemsTracking(c->db, o);
+        }
+        signalModifiedKey(c, c->db, c->argv[1]);
+        notifyKeyspaceEvent(NOTIFY_HASH, "hgetdel", c->argv[1], c->db->id);


Are we aligned on adding a new keyspace event? I was thinking that since we only trigger this when we delete, we could just trigger an hdel keyspace event?

I would also agree with hdel. I was unsure about it so I kept hgetdel

src/t_hash.c

ranshid · 2025-11-17T22:19:56Z

src/commands/hgetdel.json

+{
+    "HGETDEL": {
+        "summary": "Returns the values of one or more fields and deletes them from a hash.",
+        "complexity": "O(N) where N is the number of fields to be retrieved and deleted.",


Personally I agree this should be O(N), but we should then fix the inconsistency, since for other commands we marked them as O(1) following PR review (eg httl, hpttl, hsetex etc...) HOWEVER for HMGET we did use O(N), so lets decide on the correct form and align all command docs. @valkey-io/core-team FYI

I believe it needs to be O(N) as we will be looping over the number of fields.

ranshid · 2025-11-17T22:29:20Z

I have one question: In Redis 8.0, it introduces this command HGETDEL, the open source license was changed before Redis 8.0. I am not sure how many users migrating from Redis 8.0 to Valkey? Do we need still align with the Redis weird syntax?

Honestly, I do not like the format: HGETDEL key FIELDS numfields field [field ...]

I also do not like the FIELDS (although it has advantages for adding future command arguments), but I agree with the state that we should be more aligned with the client ecosystem needs and I think it is overriding personal taste ATM.

rueian · 2025-11-17T23:11:16Z

As a client maintainer, I suggest aligning with the weird syntax as long as the command name remains the same.

Signed-off-by: Roshan Khatri <[email protected]>

yangbodong22011 · 2025-11-18T03:10:06Z

I vote for use Redis syntax. (for save time and compatibility, Redis client for Valkey, Valkey client for Redis)

P.S. Actually, client can support both two syntax use two api.

ranshid · 2025-11-18T08:26:33Z

@valkey-io/core-team Let me summarize the decision points:

Should we support this new API? this functionality is already available since Valkey 9.0 (eg HGETEX myhash EX 0 FIELDS ....)
Should we duplicate the Redis API? The majority of comments here suggest we do. This will probably make it easier for client libraries to support it ifor both Redis and Valkey
Order regarding command complexity. When we introduced HFE we decided to set the complexity of variadic commands.
I think O(N) sounds better but in that case we need to take an action item to align other commands (can/should be in a separate PR)
keyspace notifications: Currently the decision is to produce keyspace evenets ONLY when there are actually mutations oin the objects. we will trigger a SINGLE hdel event in case we deleted at least 1 field and del event in case the object was deleted after all fields deleted.

hwware · 2025-11-18T15:58:27Z

If it's the same syntax as in Redis 8, I vote YES.

It is not, but I can make it the same

Now the syntax is same as redis https://redis.io/docs/latest/commands/hgetdel/

ranshid · 2025-11-19T05:51:20Z

@valkey-io/core-team do you want to try and take a decision offline (on this PR) or should I schedule this to be a topic on Monday?
Seems to me it might not require an extensive talk so maybe we can push this by aligning offline?

hwware · 2025-11-19T15:51:05Z

@valkey-io/core-team Let me summarize the decision points:

Should we support this new API? this functionality is already available since Valkey 9.0 (eg HGETEX myhash EX 0 FIELDS ....)

I vote yes, we can have this new command API

Should we duplicate the Redis API? The majority of comments here suggest we do. This will probably make it easier for client libraries to support it ifor both Redis and Valkey

According to above comments from some contributors, it looks like it is better to align with Redis command syntax

Order regarding command complexity. When we introduced HFE we decided to set the complexity of variadic commands.
I think O(N) sounds better but in that case we need to take an action item to align other commands (can/should be in a separate PR)

Yes, O(n) is fine

keyspace notifications: Currently the decision is to produce keyspace evenets ONLY when there are actually mutations oin the objects. we will trigger a SINGLE hdel event in case we deleted at least 1 field and del event in case the object was deleted after all fields deleted.

I agree with this part coding logic.

zuiderkwast · 2025-11-19T20:24:09Z

+1 for Wen's comments. (Yes, align with Redis syntax, O(n), single hdel event.)

ranshid · 2025-11-20T11:14:32Z

+1 for Wen's comments. (Yes, align with Redis syntax, O(n), single hdel event.)

O.K so we have 2 TSC approvers. @zuiderkwast should we still wait for the next meeting or start driving it here? (simply asking: should I remove the majority needed?)

sarthakaggarwal97 · 2025-11-20T16:43:09Z

src/t_hash.c

 }

+void hgetdelCommand(client *c) {
+    int fields_index = 4;


Can we add a small comment like this to explain why 4.

/* argv: [0]=HGETDEL, [1]=key, [2]=FIELDS, [3]=numfields, [4...]=fields */

github-actions bot assigned roshkhatri Nov 17, 2025

Adds HGETDEL Support to Valkey

fddacdb

Signed-off-by: Roshan Khatri <[email protected]>

roshkhatri force-pushed the hgetdel branch from 98da96e to fddacdb Compare November 17, 2025 08:35

roshkhatri mentioned this pull request Nov 17, 2025

[NEW] HGETDEL support in Valkey #2850

Open

hwware added the major-decision-pending Major decision pending by TSC team label Nov 17, 2025

hpatro reviewed Nov 17, 2025

View reviewed changes

hpatro requested a review from ranshid November 17, 2025 19:59

roshkhatri added 2 commits November 17, 2025 19:59

Aligns the syntax with redis commands

07e548f

Signed-off-by: Roshan Khatri <[email protected]>

remove extra blank line

714da0f

Signed-off-by: Roshan Khatri <[email protected]>

ranshid added needs-doc-pr This change needs to update a documentation page. Remove label once doc PR is open. release-notes This issue should get a line item in the release notes labels Nov 17, 2025

ranshid reviewed Nov 17, 2025

View reviewed changes

optimize loop and address feedback

658054d

Signed-off-by: Roshan Khatri <[email protected]>

sarthakaggarwal97 reviewed Nov 20, 2025

View reviewed changes

Adds HGETDEL Support to Valkey #2851

Are you sure you want to change the base?

Adds HGETDEL Support to Valkey #2851

Conversation

roshkhatri commented Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

hwware commented Nov 17, 2025

Uh oh!

hwware commented Nov 17, 2025

Uh oh!

zuiderkwast commented Nov 17, 2025

Uh oh!

roshkhatri commented Nov 17, 2025

Uh oh!

zuiderkwast commented Nov 17, 2025

Uh oh!

roshkhatri commented Nov 17, 2025

Uh oh!

JimB123 commented Nov 17, 2025

Uh oh!

hpatro left a comment

Choose a reason for hiding this comment

Uh oh!

nihohit commented Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

roshkhatri commented Nov 17, 2025

Uh oh!

hwware commented Nov 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ranshid left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ranshid Nov 17, 2025

Choose a reason for hiding this comment

Uh oh!

roshkhatri Nov 17, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ranshid Nov 17, 2025

Choose a reason for hiding this comment

Uh oh!

roshkhatri Nov 17, 2025

Choose a reason for hiding this comment

Uh oh!

ranshid commented Nov 17, 2025

Uh oh!

rueian commented Nov 17, 2025

Uh oh!

yangbodong22011 commented Nov 18, 2025

Uh oh!

ranshid commented Nov 18, 2025

Uh oh!

hwware commented Nov 18, 2025

Uh oh!

ranshid commented Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hwware commented Nov 19, 2025

Uh oh!

zuiderkwast commented Nov 19, 2025

Uh oh!

ranshid commented Nov 20, 2025

Uh oh!

sarthakaggarwal97 Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

roshkhatri commented Nov 17, 2025 •

edited

Loading

codecov bot commented Nov 17, 2025 •

edited

Loading

nihohit commented Nov 17, 2025 •

edited

Loading

hwware commented Nov 17, 2025 •

edited

Loading

ranshid commented Nov 19, 2025 •

edited

Loading