[backport] Backport sweep for 9.0

[valkeyrie-ops]

Backport sweep for 9.0

Automated cherry-picks from PRs marked "To be backported".

Applied

Source PR	Title	Detail
#3459	Fix missing signalModifiedKey calls for stream commands	conflicts resolved by Claude Code
#4613	Move build-debian-old CI job to Debian Bookworm
#4676	Fix return types of three module API declarations to match definitions	conflicts resolved by Claude Code

AI resolution details are posted as comments on this PR when available.

Needs attention

These candidates could not be applied automatically and need a maintainer to follow up.

1 candidate(s)

Source PR	Title	Outcome	Reason
#4574	Fix script debugger uaf	skipped-conflict	target branch lacks conflicted file(s): src/modules/lua/debug_lua.c, src/modules/lua/engine_lua.c

---

Generated by valkey-ci-agent using Claude Code.

[valkeyrie-ops]

AI backport resolution: source PR #3459

Fix missing signalModifiedKey calls for stream commands

2 AI-edited files

Claude Summary

All conflicts are resolved. Both files are free of conflict markers, src/t_stream.c passes a gcc syntax check, and both Tcl files have balanced braces.

Here's how each conflict was handled:

src/t_stream.c (5 conflicts, all caused by two branch differences: 9.0 uses o->ptr/c->argv[n]->ptr where the source branch uses objectGetVal(), and 9.0 has no XDELEX/XACKDEL support):

• xgroupCommand CREATE (MKSTREAM block): kept 9.0's s = o->ptr accessor and took the PR's change of removing the early signalModifiedKey there (it now fires in the if (cg) success path instead).
• xgroupCommand CREATECONSUMER: kept 9.0's c->argv[4]->ptr call convention and added the PR's if (created) signalModifiedKey(...) line.
• xclaimCommand and xautoclaimCommand consumer creation: kept 9.0's c->argv[3]->ptr convention and added the PR's modified = 1 on consumer creation.
• xdelCommand tail: kept the 9.0 side unchanged. The incoming side was the 9.2 xdelGeneric body with XDELEX/XACKDEL propagation (has_pelmode, acked, streamPropagateAckIDs), none of which exists on 9.0 — I confirmed XDELEX appears nowhere on this branch. The PR's "don't emit xdel for DELREF" tweak only applies to that generic path, so it has no counterpart to backport here.

tests/unit/type/stream.tcl: resolved to the HEAD (9.0) side, i.e. no change. The conflict was one giant block of ~890 lines of XDELEX/XACKDEL tests that exist only on the source branch; the PR's actual change to this file was deleting one of those tests, which doesn't exist on 9.0.

tests/unit/type/stream-cgroups.tcl: auto-merged cleanly with the PR's three new WATCH-dirtying tests (+95 lines). I verified the helpers it uses (valkey_deferring_client, wait_for_blocked_clients_count) exist on the target branch, so no adaptation was needed.

The resolved commit is +123/−3 versus upstream's +125/−42; the smaller deletion count is entirely the XDELEX-related removals that have no counterpart on 9.0.
... summary truncated.

AI-edited files requiring review

• src/t_stream.c — view diff
• tests/unit/type/stream.tcl — view diff

Full backport commit diff: commit ae244d5ffcdf.

Please review these AI resolutions for correctness before merging.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: ba73428a-2890-40b5-992a-5790da3549c7

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[valkeyrie-ops]

AI backport resolution: source PR #4676

Fix return types of three module API declarations to match definitions

1 AI-edited file

Claude Summary

The conflict is resolved. Here's a summary of what I did:

Conflict analysis: The single conflict in src/valkeymodule.h was in the block of VALKEYMODULE_API function-pointer declarations (the module API table externs), specifically around the ACL entry declarations. The conflict arose because unstable has a ValkeyModule_ACLCheckPermissions declaration adjacent to the changed lines that doesn't exist on the 9.0 branch — I confirmed with grep that ACLCheckPermissions appears nowhere else in the 9.0 sources (no VM_ACLCheckPermissions implementation in src/module.c), so it was purely conflicting context, not part of the fix.

Resolution: I took the incoming side's actual change — declaring ValkeyModule_ACLAddLogEntry and ValkeyModule_ACLAddLogEntryByUserName as returning int instead of void (matching their int VM_ACLAddLogEntry / int VM_ACLAddLogEntryByUserName implementations at src/module.c:10109 and src/module.c:10123) — while dropping the unstable-only ACLCheckPermissions declaration that doesn't belong on 9.0. The third fix from the PR, ValkeyModule_FreeModuleUser changing to int (src/valkeymodule.h:1860), had already auto-merged cleanly, as did the doc-comment addition in src/module.c noting that VM_FreeModuleUser returns VALKEYMODULE_OK.

Verification: No conflict markers remain in either file, the header passes gcc -fsyntax-only, and the resolved diff (+11/−9 lines across both files) matches the upstream PR's size (+12/−10). I did not stage or commit anything, per the constraints.

AI-edited files requiring review

• src/valkeymodule.h — view diff

Full backport commit diff: commit 3c109627a9e2.

Please review these AI resolutions for correctness before merging.

[valkeyrie-ops]

Automatic follow-up for the current backport head.

I did not push a fix: This is a timing-dependent failure specific to the valgrind environment: the identical test passed in 20+ other jobs of the same run, and the dataset visibly changed between two back-to-back assertions due to replication link churn. No default-branch candidate commit fixes this test or this race, and the failing assertion is the core invariant the test exists to verify, so the only 'fixes' available would weaken the test or paper over a possible product-level race. No safe, attributable deterministic fix exists.

Looked at the failure from this run.