tokio-rs/mini-redis

This system is a mini-Redis implementation providing both a server and a client library for key-value storage and pub/sub messaging. It supports standard Redis commands like GET, SET, and PING, along with optional OpenTelemetry tracing for observability. The client library offers asynchronous, blocking, and buffered connection modes to accommodate different usage patterns.

The examples directory now includes functional demonstrations for connecting to a mini-redis server, including a basic key-value set/get operation (hello\_world.rs), a publish/subscribe workflow (pub.rs and sub.rs), and a chat example stub. These examples provide users with concrete, runnable code snippets to understand how to use the mini-redis client library for common tasks like setting keys, retrieving values, and subscribing to channels.

examples · high confidence

The \src/clients\ module now exposes two additional client types alongside the existing asynchronous \Client\. \BlockingClient\ allows synchronous usage by wrapping the async client in a Tokio current-thread runtime, enabling blocking calls for \connect\, \get\, \set\, \set\_expires\, and \publish\. \BufferedClient\ enables sharing a single Redis connection across multiple asynchronous tasks by buffering commands through a channel and a dedicated background task, supporting \get\ and \set\ operations.

src/clients · high confidence

The server now supports the PING command, allowing clients to verify connection liveness or measure latency by sending an optional message that is echoed back. Additionally, the command dispatcher has been refactored to handle unrecognized commands gracefully: instead of terminating the connection with an error, the server now returns a standard Redis error response (ERR unknown command) and keeps the client connection alive, improving resilience for clients issuing unsupported or mistyped commands.

src/cmd · high confidence

The project now includes explicit binary entry points in \src/bin/cli.rs\ and \src/bin/server.rs\, replacing previous ad-hoc or library-only execution modes. The CLI binary (\mini-redis-cli\) uses \clap\ to expose Redis commands (Ping, Get, Set, Publish, Subscribe) with options for host, port, and key expiration, running on a single-threaded Tokio runtime. The server binary (\mini-redis-server\) also uses \clap\ for port configuration and initializes logging via \tracing\_subscriber\; when the \otel\ feature is enabled, it configures OpenTelemetry tracing with AWS X-Ray propagation and OTLP export. This change centralizes argument parsing and runtime setup in dedicated binaries rather than scattering them across library code or test files.

src/bin · high confidence

The internal architecture of the server and client has been restructured to improve modularity and protocol correctness. The previous \conn.rs\ and \kv.rs\ modules have been replaced by new \connection.rs\ and \db.rs\ implementations, introducing a dedicated \Connection\ struct for frame-level I/O and a \Db\ struct with a background task for key expiration. The \Frame\ enum has been updated to store arrays as \Vec\<Frame\>\ instead of \Vec\<Box\<Frame\>\>\, and the protocol parser now strictly validates NULL bulk strings and provides detailed error messages for invalid formats. Additionally, the public API has been expanded by making \Frame\, \Error\, and various parsing methods public, while the old \client.rs\ stub was removed in favor of a new \clients\ module.

src · high confidence

Added new test files (\tests/client.rs\, \tests/buffered\_client.rs\, \tests/server.rs\, \tests/frame\_validation.rs\) that verify core Redis protocol behaviors. These tests cover key-value get/set operations, pub/sub messaging, client ping responses, and strict validation of RESP frame formats (such as rejecting invalid negative bulk lengths).

tests · high confidence

The mini-redis client and server have been upgraded to version 0.4.1, migrating the core runtime from Tokio 0.2 to Tokio 1.0 and updating the \bytes\ crate to version 1. The CLI tool now uses \clap\ for argument parsing, and the project introduces optional OpenTelemetry integration (via \opentelemetry\, \tracing-opentelemetry\, \opentelemetry-aws\, and \opentelemetry-otlp\) enabled through the \otel\ feature flag. Other dependency updates include \async-stream\ to 0.3.0 and \atoi\ to 2.0.0.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 62 → 63 (+1.4)
• Rubric changed (rubric-2026.09.11 → rubric-2026.09.18) — scores are not directly comparable.

• Code Health 100 → 100 (+0.0)
• Architecture 100 → 91 (-9.0)
• Maturity 48 → 48 (+0.2)
• Readiness 50 → 58 (+8.1)
• Security 94 → 95 (+1.6)
• Performance 100 (new)

• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• Off-boarding risk: anonymized user #1

• Dependency hygiene PARTLY measured — Cargo dependencies read, dependency currency not (crates.io unreachable)
• Inconsistent construction pattern. BufferedClient uses a static-style method 'buffer' to create an instance, whereas Client and BlockingClient use 'connect'. This breaks the mental model of 'creating a client' across the library.
• Inconsistent parameter types for subscription. Client and BlockingClient take a single String, while Subscriber takes a slice of Strings (&[String]). This forces users to handle different data structures depending on which client type they are using, even though the intent (subscribing to channels) is the same.
• Off-boarding risk: anonymized user #1
• Redundant connection logic across client types. Both BlockingClient and Client expose an identical connect method. Since BlockingClient is likely a wrapper or specific implementation of Client, this creates duplication in the public API surface for initialization.

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

tokio-rs/mini-redis was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.