DOC-7012 Declare futures-util so rust-async cmds_generic compiles - #3896
Merged
Conversation
`run_rust_async`'s Cargo.toml deps string never declared `futures-util`, so `cargo test` failed with `unresolved import futures_util` wherever an example calls `.collect().await` on an `AsyncIter` (needs `StreamExt` in scope). cmds_generic's rust-async example already imports `futures_util::StreamExt` correctly for its four scan steps — the crate itself was just never wired into the harness. This was mischaracterized on DOC-6968 as "async iteration API drift in the pinned redis-rs." It isn't: the example's own import was already correct, and redis-rs's `AsyncIter` hasn't changed shape. It's a plain missing dependency in the harness's own Cargo.toml template. Regression-checked every other rust-async set. cmds_stream and client-specific still fail, both for reasons unrelated to this fix: the ambient local Redis 7.2.7 doesn't support IDMP (cmds_stream's xadd2, same gap as DOC-7011's HEXPIRE/FT.CREATE/TS.CREATE case), and client-specific needs the redis crate's `json` feature plus `serde_json`, neither declared here (RedisJSON support, out of scope for this ticket). Learned: rust_run only writes work/rust-async/Cargo.toml if it doesn't already exist, so a deps-string edit in run.sh needs the cached Cargo.toml (and Cargo.lock) deleted before the new dependency takes effect — same caching trap as the Java pom.xml one already in memory, just for Cargo instead of Maven Constraint: Cargo.toml uses the hyphenated crate name `futures-util`; Rust source imports it as `futures_util` (underscore) — Cargo translates automatically, don't "fix" the hyphen to match the import Gaps: client-specific/rust-async fails on missing JsonAsyncCommands/serde_json (RedisJSON support never wired into this harness) — separate issue, worth its own ticket if RedisJSON rust-async examples are added later Ticket: DOC-7012
Contributor
Contributor
🧠 Redis MemoryFound 5 related items from repository history (5 new this commit):
Memory updated at bb167fb |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DOC-7012
What
run_rust_async's Cargo.toml deps string in the test harness never declaredfutures-util, socargo testfailed withunresolved import futures_utiloncmds_generic's rust-async example — which needsfutures_util::StreamExtin scope to.collect().awaitanAsyncIter(used by its fourscansteps).Correcting the original diagnosis
DOC-6968 characterized this as "async iteration API drift in the pinned redis-rs." That turned out to be wrong: the example's own
use futures_util::StreamExt;import was already correct, andredis-rs'sAsyncIterhasn't changed shape. It's a plain missing dependency in the harness's own Cargo.toml template — nothing to do with the pinned redis-rs version.Verification
build/example-test-harness/run.sh cmds_generic rust-async→ PASS (was a compile failure before). Had to delete the cachedwork/rust-async/Cargo.toml/Cargo.lockfirst —rust_runonly writesCargo.tomlif absent, so a deps-string edit inrun.shdoesn't take effect against a stale cache (the same trap as the Javapom.xmlcaching gotcha).cmds_cnxmgmt,cmds_hash,cmds_list,cmds_servermgmt,cmds_set,cmds_sorted_set,cmds_stream,cmds_string,set_and_get,client-specific): all still pass or SKIP as before, except two pre-existing, unrelated failures — confirmed by their actual error text, not assumed:cmds_stream'sxadd2fails because the ambient local Redis (7.2.7) doesn't support IDMP — the same category of gap as DOC-7011'sHEXPIRE/FT.CREATE/TS.CREATE.client-specificfails on a missingJsonAsyncCommands/serde_json(RedisJSON support was never wired into this harness at all) — unrelated tofutures-util, out of scope here.🤖 Generated with Claude Code
Note
Low Risk
Test-harness-only dependency template change; no production or library code paths affected.
Overview
Fixes rust-async example compilation in the test harness by correcting the
run_rust_asyncCargo dependency snippet and declaringfutures-util = "0.3"alongsideredis(tokio-comp) andtokio.Examples such as
cmds_genericalready importfutures_util::StreamExtfor asyncscaniteration; the failure was an unresolved import because the harness-generatedCargo.tomlnever listed that crate—not a redis-rs API change.Reviewed by Cursor Bugbot for commit bb167fb. Bugbot is set up for automated code reviews on this repo. Configure here.