Fix IFDEQ/IFDNE digest argument type in SET and DELEX command json file#15305
Conversation
There was a problem hiding this comment.
I think this test is an overkill and should be removed. @sundb WDYT?
As a side note, maybe it's a good idea to have some sort of tests to avoid these kinds of mistakes, but they have to be generic (written once, and not for each new param/cmd) and also this is outside the scope of this PR.
There was a problem hiding this comment.
I think this test is an overkill and should be removed. @sundb WDYT?
agree with you.
As a side note, maybe it's a good idea to have some sort of tests to avoid these kinds of mistakes, but they have to be generic (written once, and not for each new param/cmd) and also this is outside the scope of this PR.
Maybe we can verify it in req-res-log-validator.py
The IFDEQ/IFDNE match-digest argument of SET and DELEX was declared as "integer" in the command JSON, but it is actually a hexadecimal string: the implementation validates it with validateHexDigest() (requiring exactly DIGEST_HEX_LENGTH hex characters) and compares it with strcasecmp(), and DIGEST/stringDigest() produce the value via a PRIx64 hex format. The sibling IFEQ/IFNE match-value arguments are already correctly typed as "string". Change the type to "string" in set.json and delex.json and regenerate commands.def.
daguimu
force-pushed
the
fix/ifdeq-ifdne-digest-arg-type
branch
from
6493de6 to
3354a44
Compare
|
Thanks @minchopaskal @sundb — removed the test. The PR is now just the metadata type fix ( |
sundb
changed the title
3 participants
Summary
The
IFDEQ/IFDNEmatch-digest argument ofSETandDELEXis declared asintegerin the command metadata, but it is actually a hexadecimal string. This makesCOMMAND DOCS/COMMAND INFOreport a wrong argument type to clients and tooling (e.g. client libraries that generate bindings or validate arguments from command metadata).What changed
src/commands/set.json,src/commands/delex.json: changeifdeq-digest/ifdne-digesttypefromintegertostring.src/commands.def: regenerated from the JSON viautils/generate-command-code.py.tests/unit/introspection-2.tcl: add a test assertingCOMMAND DOCSreports theIFDEQ/IFDNEdigest arguments asstringfor bothSETandDELEX.Why this is correct
The digest argument is a fixed-length hex string, not an integer:
validateHexDigest()insrc/t_string.c, which requires exactlyDIGEST_HEX_LENGTH(16) hexadecimal characters.strcasecmp()(string comparison) insetGenericCommand()(src/t_string.c) anddelexCommand()(src/db.c).DIGEST/stringDigest()produce the value with aPRIx64hex format, so a typical digest such asf7042be43fb80714is not a valid integer.The sibling
IFEQ/IFNEmatch-valuearguments are already correctly typed asstring.Test plan
SET/DELEX IFDEQ/IFDNE digest arguments are typed as stringpasses.integermakes the new test fail, confirming it exercises the change.unit/introspection-2suite passes.Note
Low Risk
Documentation and generated introspection tables only; no runtime command logic changes.
Overview
Corrects command introspection metadata for
SETandDELEXsoIFDEQ/IFDNEdigest operands are documented asstring, notinteger.Updates
src/commands/set.jsonandsrc/commands/delex.json, with matching regeneration insrc/commands.def.COMMAND DOCS/COMMAND INFO(and tooling that consumes them) will now report hex digest arguments consistently withIFEQ/IFNEvalue args and with runtime handling (hex string validation/comparison). No change to command parsing or server behavior—only the published argument types.Reviewed by Cursor Bugbot for commit 3354a44. Bugbot is set up for automated code reviews on this repo. Configure here.