[Epic] Rust client wrapper – Preview #6519

Activity

1. yipin-chen

   added

   Task 🔧Implementation work (not a bug)Implementation work (not a bug)

   Rust ⚙️Pull requests that update rust codePull requests that update rust code

   on Jul 13, 2026
2. yipin-chen

   added this to the 2.6 milestone on Jul 13, 2026
3. omerrubi-amzn commented on Jul 29, 2026

   

   omerrubi-amzn

   on Jul 29, 2026

   Last edited by omerrubi-amzn

   Collaborator

   More actions

   Deliverables for the Rust preview release. The client itself is preview-ready (async+sync, full command coverage, IAM/PubSub/OpenTelemetry, 3-layer test suite green in CI over Valkey 8.1/8.0/7.2 + Redis 7.2 × x64/arm64); remaining work is release/packaging.

   TLV team

   • Client feature-complete for preview (async+sync, unified command surface + extension traits, custom_command, batches/transactions, dynamic auth incl. AWS IAM, runtime Pub/Sub, OpenTelemetry)
   • Test suite: unit/mock + live integration (RESP2/RESP3, cluster/TLS/auth) + doctests + redis-rs parity guard — green in CI
   • Finalize crate naming. e.g.: glide-rs / glide-rust / glide-core / glide-telemetry / glide-logger / glide-core-aux (forked redis-rs)
   • Publish the internal crate chain to crates.io from the glide-core workspace, in dependency order:
     • ../logger_core → glide-logger
     • ./telemetry (telemetrylib) → glide-telemetry
     • ./redis-rs/redis (forked redis-rs) → glide-core-aux (new name)
     • glide-core → glide-core
     • wrapper repo: switch git deps → versioned dep (glide-core = "x.y")
   • Docs: README / DESIGN / DEVELOPER / CHANGELOG — pending review from team + PM; docs.rs pending publish

   VAN team

   • CI/CD: release/publish workflow — publishes the crate chain in dependency order + version tagging (cargo publish --workspace on Cargo 1.90+)
   • Package management: crates.io publishing of the chain (source in glide-core repo)
   • Performance framework: integrate into cross-language benchmark harness

   Decisions

   Open: the wrapper crate is on its own repo under valkey-io. Our recommendation is that the redis-rs fork, logger_core, and telemetrylib stay embedded in the glide-core repo (no separate repos) and are published to crates.io from that workspace. Additional crates - glide-core, redis-rs fork, logger_core, telemetry.

   Open — preview delivery: recommendation is to ship the preview from crates.io (publish chain on the preview critical path), rather than a git-installable preview.
4. jeremyprime commented on Jul 31, 2026

   

   jeremyprime

   on Jul 31, 2026

   Collaborator

   More actions

   A few thoughts:

   1. The vendored redis-rs crate should use a more descriptive name, glide-core-aux does not say what it is. Preferably glide-redis, or something protocol-related like glide-resp or glide-protocol. So the full set of names would be glide-logger, glide-telemetry, glide-redis (or whatever we choose), glide-core, and glide (main wrapper/client).
   2. The internal crates should all use 0.x versions to signal they are not meant for direct consumption (README in crates.io would also specify that). The wrapper would follow the same versioning as other clients (e.g. 2.6.0).
   3. We can use dual path and version dependencies to ensure they work locally, in CI, and via crates.io (e.g. logger_core = { path = "../logger_core", version = "0.1" }).
   4. As part of the preview release we should audit the core and ensure that no internals (classes, env vars, etc) are leaked to avoid having to make breaking changes later. Internal crate methods/types like CoreClient should not be exposed. And env vars (GLIDE_NAME, GLIDE_VERSION) should have defaults so users don't have to set these themselves.

   Regarding the open decisions:

   • The wrapper should live in this repo (new rust/ dir), not a separate repo. The wrapper is tightly coupled to the other Rust crates, and most changes to the core and other crates will also require a change to the wrapper at the same time (not the case for other clients that use an FFI layer/API). Also, the Rust crates must all be published so it would be much easier to publish together in the same repo/CI.
   • Agree we should do a preview/RC release, the internal clients could just use 0.x versions and the wrapper could use a *-rc version to start, published in dependency order (glide-logger, glide-telemetry, glide-redis, glide-core, glide).
5. jeremyprime commented on Aug 7, 2026

   

   jeremyprime

   on Aug 7, 2026

   Collaborator

   More actions

   VAN team (updated)

   Assumes the wrapper is in this repo (rust/ dir), crates are renamed with glide- prefix, and internal crates use 0.x versions with dual path and version dependencies (per discussion above).

   1. Pre-publish readiness

   • Fix GLIDE_VERSION/GLIDE_NAME env vars to have defaults (no .cargo/config.toml needed for users)
   • Perform an API surface audit; hide core() accessor, add #[non_exhaustive] to error type, update crate metadata/descriptions

   2. CI/CD

   • Add rust-client.yml workflow (lint, build, test matrix, cargo-deny); rename existing rust.yml → rust-core.yml
   • Create rust-client-cd.yml publish workflow (5 crates in dependency order) and crates.io team ownership/tokens

   3. Publish and verify

   • Publish the crate chain: glide-logger → glide-telemetry → glide-redis → glide-core → glide (RC version)
   • Verify that docs.rs renders, cargo add glide works in fresh project without extra config

   4. Performance framework

   • Add Rust client to benchmark framework and establish baselines

   Decisions

   • Should we add Rust client support to resp-bench or update the existing benchmark tool under benchmarks/?
6. currantw

   added sub-issues on Aug 24, 2026

   • [Task] Add Makefile targets for the Rust client #6865
   • [Task] Add a lint job for the Rust client #6867
   • [Task] Remove deny.toml and rustfmt.toml from Rust client #6868
   • [Task] Cache rust/target in the Rust client tests job #6869
   • [Task] Rust client test workflow parity with other clients #6870
   • [Task] Add a dependabot cargo entry for the Rust client #6871
7. currantw

   self-assigned this

   on Aug 24, 2026
8. currantw

   added sub-issues on Aug 24, 2026

   • [Task] Restrict SCAN on cluster clients (use cluster_scan) #6872
   • [Task] Default GLIDE_VERSION at compile time and drop redundant rust/.cargo/config.toml env vars #6876
9. 21 remaining items

   Load more
10. currantw

    added sub-issues on Aug 28, 2026

    • Rust: Add SecureTls integration test coverage #6932
    • Rust: Split HGETEX/HSETEX expiry types so invalid options are unrepresentable #6934
11. currantw

    added 2 commits that reference this issue on Aug 28, 2026

    build(rust): use in-repo path deps for glide-core and redis fork

    ...

    9f5b885

    ci(rust): scan the rust client with cargo-deny against the root config

    ...

    8848b10
12. currantw

    added a sub-issue on Aug 31, 2026

    • [Task] Rust: Declare rust-version #6959
13. currantw

    removed a sub-issue on Aug 31, 2026

    • [Task] Rust: Declare rust-version #6959
14. currantw

    added a sub-issue on Aug 31, 2026

    • rust: scan iterators silently swallow errors as end-of-scan #6964
15. currantw

    added a sub-issue on Sep 8, 2026

    • [Task] Hide internal types from the Rust client public API #7024
16. yipin-chen

    pinned this issue on Sep 10, 2026
17. currantw

    added a sub-issue on Sep 11, 2026

    • [Task] Update Rust client command signatures for redis-rs 1.7.0 compatibility #7058
18. currantw

    added sub-issues on Sep 22, 2026

    • [Task] Harden the Rust command-table parity guard (compare bodies, fail-closed) #7154
    • [Task] Declare and CI-gate an MSRV for the Rust client (publish-readiness) #7167
19. yipin-chen

    closed this as completedon Oct 9, 2026
20. yipin-chen commented on Oct 9, 2026

    

    yipin-chen

    on Oct 9, 2026

    CollaboratorAuthor

    More actions

    Preview release is released on Oct 6.
21. yipin-chen

    unpinned this issue on Oct 13, 2026