Trigger prepareCommand on argc change in module command filters by phermansson · Pull Request #2945 · valkey-io/valkey

phermansson · 2025-12-17T13:44:04Z

Previously, only changes to argv[0] were considered when deciding whether to re-prepare the command and recompute the cluster slot. This caused issues where changes to the argument count (argc) would not trigger the necessary prepare in case additional keys were injected to the command

This fix adds a check to ensure that changes to argc are properly considered.

phermansson · 2025-12-17T14:12:47Z

Background

Our valkey module is injecting a secondary key into a module defined command using a filter function registered with RegisterCommandFilter. The command is registered using

RedisModule_CreateCommand(ctx, "module.set", module_set, "write deny-oom", 1, **2**, 1) == REDISMODULE_ERR)

But the client will only send the first key and the second key is applied to using the filter callback.

I noticed that this do no longer work in Valkey 9, instead of a successful call we instead get a
CROSSSLOT Keys in request don't hash to the same slot

I believe that this is because the slot validation now is done prior to the filter callback being called, before the second key has been added.

Solution

I found a way to fix this by extending the condition that evaluate if the command has changed after the filter callback was called, to also validate if the number of argument have changed. While there may still be cases where a filter alters the command in other ways that would require running prepareCommand(), adding argc validation covers the majority of use cases and should be a good balance between correctness and performance.

zuiderkwast · 2025-12-17T14:54:06Z

It works in 8.1 and only fails in Valkey 9? You think it's a regression from #2165?

zuiderkwast

Great, thanks! We should release it in the next patch release which will be 9.0.2.

This would affect not only module-defined commands but also regular commands when command filters are changing the command args, right?

Ideally, we should cover this with a test case. There are some for command filters here:

Previously, only changes to argv[0] were considered when deciding whether to re-prepare the command and recompute the cluster slot. This caused issues where changes to the argument count (argc) would not trigger the necessary prepare in case additional keys were injected to the command This fix adds a check to ensure that changes to argc are properly considered. Signed-off-by: Patrik Hermansson <phermansson@gmail.com>

hpatro

Could you cite the usecase of inserting a secondary key over the actual key ? Sounds really interesting to me.

phermansson · 2025-12-17T20:45:22Z

It works in 8.1 and only fails in Valkey 9? You think it's a regression from #2165?

Yes. Our module works well with both 8.0 and 8.1 and we started to observe issues when moving to 9.0.

This appears to be related to #2165. I tested our module against a private Valkey build based on the commit immediately preceding #2165, where everything worked as expected. The same module starts failing once the build includes #2165.

codecov · 2025-12-17T21:19:06Z

Codecov Report

❌ Patch coverage is 0% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.42%. Comparing base (8ab0152) to head (b7d8d5c).
⚠️ Report is 38 commits behind head on unstable.

Files with missing lines	Patch %	Lines
src/module.c	0.00%	7 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #2945      +/-   ##
============================================
+ Coverage     72.28%   72.42%   +0.13%     
============================================
  Files           129      129              
  Lines         70540    70543       +3     
============================================
+ Hits          50993    51088      +95     
+ Misses        19547    19455      -92

Files with missing lines	Coverage Δ
src/module.c	`9.76% <0.00%> (-0.01%)`	⬇️

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

hpatro · 2025-12-17T22:23:07Z

+    /* If filter changed the command or number of arguments, redo prepareCommand */
+    const bool command_changed = (c->argv[0] != pre_filter_command);
+    const bool argc_changed = (c->argc != pre_filter_argc);


I was thinking more about this. Does this suffice for all module developers? What if the module developer is keeping the command and arg count constant but changes the key itself ? Should we be introducing a flag to indicate to the server to re-prepare the command ?

I was thinking about this problem as well. The patch only solves part of the possible scenarios and the reason that I did not want to compare all arguments was because such change would most likely have some performance impact.

Adding a flag or a function within the module-API which could be used to tell the server to re-prepare sounds like a good suggestion which would eliminate that cost.

phermansson · 2025-12-18T07:54:00Z

Could you cite the usecase of inserting a secondary key over the actual key ? Sounds really interesting to me.

Sure!

We need to maintain metadata for certain operations in a secondary data structure within Valkey. This secondary structure is an internal implementation detail and should not be exposed to the client. To ensure correct placement in a clustered environment, we always make sure that the metadata key is in the same hash slot as the primary key.

This secondary data structure needs to be present if the primary key is present, which present some challenges running in a clustered environment. To avoid ending up in an inconsistent state where either the primary key or its metadata is migrated independently, we must ensure that both keys are considered together. By declaring both the primary key and the metadata key as 'command keys', Valkey cluster logic validates the state of both keys when the operation is executed during migrate/import of that slot.

…ey-io#2945) Previously, only changes to argv[0] were considered when deciding whether to re-prepare the command and recompute the cluster slot. This caused issues where changes to the argument count (argc) would not trigger the necessary prepare in case additional keys were injected to the command This fix adds a check to ensure that changes to argc are properly considered. Signed-off-by: Patrik Hermansson <phermansson@gmail.com>

Previously, only changes to argv[0] were considered when deciding whether to re-prepare the command and recompute the cluster slot. This caused issues where changes to the argument count (argc) would not trigger the necessary prepare in case additional keys were injected to the command This fix adds a check to ensure that changes to argc are properly considered. Signed-off-by: Patrik Hermansson <phermansson@gmail.com>

…ey-io#2945) Previously, only changes to argv[0] were considered when deciding whether to re-prepare the command and recompute the cluster slot. This caused issues where changes to the argument count (argc) would not trigger the necessary prepare in case additional keys were injected to the command This fix adds a check to ensure that changes to argc are properly considered. Signed-off-by: Patrik Hermansson <phermansson@gmail.com>

…ey-io#2945) Previously, only changes to argv[0] were considered when deciding whether to re-prepare the command and recompute the cluster slot. This caused issues where changes to the argument count (argc) would not trigger the necessary prepare in case additional keys were injected to the command This fix adds a check to ensure that changes to argc are properly considered. Signed-off-by: Patrik Hermansson <phermansson@gmail.com> Signed-off-by: Harkrishn Patro <bunty.hari@gmail.com>

…ey-io#2945) Previously, only changes to argv[0] were considered when deciding whether to re-prepare the command and recompute the cluster slot. This caused issues where changes to the argument count (argc) would not trigger the necessary prepare in case additional keys were injected to the command This fix adds a check to ensure that changes to argc are properly considered. Signed-off-by: Patrik Hermansson <phermansson@gmail.com> Signed-off-by: Ahmad Belbeisi <ahmad.belbeisi@tum.de>

…ey-io#2945) Previously, only changes to argv[0] were considered when deciding whether to re-prepare the command and recompute the cluster slot. This caused issues where changes to the argument count (argc) would not trigger the necessary prepare in case additional keys were injected to the command This fix adds a check to ensure that changes to argc are properly considered. Signed-off-by: Patrik Hermansson <phermansson@gmail.com> Signed-off-by: Ahmad Belbeisi <ahmad.belbeisi@tum.de> Signed-off-by: Ahmad Belbeisi <ahmadbelb@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 phermansson Dec 17, 2025

zuiderkwast added this to Valkey 9.0 Dec 17, 2025

zuiderkwast moved this to In Progress in Valkey 9.0 Dec 17, 2025

zuiderkwast self-requested a review December 17, 2025 15:47

zuiderkwast approved these changes Dec 17, 2025

View reviewed changes

phermansson force-pushed the fix_filter_with_argument_change branch from 6dc072a to b7d8d5c Compare December 17, 2025 19:30

hpatro approved these changes Dec 17, 2025

View reviewed changes

hpatro reviewed Dec 17, 2025

View reviewed changes

zuiderkwast merged commit 1d23866 into valkey-io:unstable Jan 8, 2026
55 checks passed

github-project-automation Bot moved this from In Progress to To be backported in Valkey 9.0 Jan 8, 2026

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Trigger prepareCommand on argc change in module command filters#2945

Trigger prepareCommand on argc change in module command filters#2945
zuiderkwast merged 1 commit into
valkey-io:unstablefrom
phermansson:fix_filter_with_argument_change

phermansson commented Dec 17, 2025

Uh oh!

phermansson commented Dec 17, 2025

Uh oh!

zuiderkwast commented Dec 17, 2025

Uh oh!

zuiderkwast left a comment

Uh oh!

hpatro left a comment

Uh oh!

phermansson commented Dec 17, 2025

Uh oh!

codecov Bot commented Dec 17, 2025 •

edited

Loading

Uh oh!

hpatro Dec 17, 2025

Uh oh!

phermansson Dec 18, 2025

Uh oh!

phermansson commented Dec 18, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

phermansson commented Dec 17, 2025

Uh oh!

phermansson commented Dec 17, 2025

Background

Solution

Uh oh!

zuiderkwast commented Dec 17, 2025

Uh oh!

zuiderkwast left a comment

Choose a reason for hiding this comment

Uh oh!

hpatro left a comment

Choose a reason for hiding this comment

Uh oh!

phermansson commented Dec 17, 2025

Uh oh!

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

Uh oh!

Codecov Report

Uh oh!

hpatro Dec 17, 2025

Choose a reason for hiding this comment

Uh oh!

phermansson Dec 18, 2025

Choose a reason for hiding this comment

Uh oh!

phermansson commented Dec 18, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

codecov Bot commented Dec 17, 2025 •

edited

Loading