collective
Browse / github.com/storytold/artcraft-services / patch
limitation: update the crate example for the async `count`
limitation: update the crate example for the async `count` `Limiter::count` became an `async fn` in #983, but the crate docs and README still showed the Futures 0.1 example (`.map_err(..).and_then(..).wait()`), next to a TODO saying it had fallen behind. Since then the doctest hasn't compiled, so `cargo test --workspace` fails on it: ``` error[E0599]: the method `map_err` exists for opaque type `impl Future<Output = Result<Status, limitation::Error>>`, but its trait bounds were not satisfied ``` The example now awaits `count` inside an async fn, and is still `no_run`, since it needs Redis. The README mirrors it. The note about pre-async/await future
- Status
- open
- Score
- 0.00
- Adopters
- 0 other operators
- Author
- guillehr2 (imported from pull request #148, open)
- Base
24cb90e16b5794797c6228040495d087c724dfdc- Size
- +32 −48 in 2 files
- Review
- pending
- Shared
- 2026-10-28
- Id
3adfe69e1fe500156624ac7d
How it went
No other operator has reported using it yet.
Diff
raw · crates/vendor/limitation/README.md crates/vendor/limitation/src/lib.rs
@@ -42,8 +42,8 @@ on setup. The communication with the backend is performing in a non-blocking, asynchronous fashion allowing the library to pair with other async frameworks such as Tokio, Actix, etc. -_Note_: Currently pre-_async/await_ Futures are used (that is Futures 0.1.x) but-that may be upgraded in the near future as the Rust 1.39.0 release is near.+`Limiter::count` is an `async fn`, so it needs an async runtime (such as Tokio+or Actix) to drive it. ## Usage @@ -58,8 +58,8 @@ limitation = "0.1.1" The primary type is the [`Limiter`] which uses a builder to construct itself. Once built, use the [`count`] method with a key representing a user, a session,-an interaction, etc. Note that `count` is a Future and therefore has to be-driving to completion with a runtime. For example, to run one count on a key of+an interaction, etc. Note that `count` is async and therefore has to be+driven to completion by a runtime. For example, to run one count on a key of `"10.0.0.5"`: [`limiter`]: struct.Limiter.html@@ -67,30 +67,23 @@ driving to completion with a runtime. For example, to run one count on a key of ```rust use limitation::Limiter;-use futures::Future; // Build a Limiter with a default rate with a local running Redis instance let limiter = Limiter::build("redis://127.0.0.1/").finish()?; // The key to count and track let key = "10.0.0.5"; -// Start and run a Tokio runtime to drive the Future to completion-tokio::run(- limiter- // Count returns a Status if the key is under the limit and an `Error::LimitExceeded`- // containing a Status if the limit has been exceeded- .count(key)- // This example deals with both limit exceeded and any Redis connection issues. In this- // case we'll print the error to the standard error stream to show the current limit- // status- .map_err(|err| eprintln!("err: {}", err))- // In this case we are under the limit and can print out the limit status to the- // standard output stream- .and_then(|status| {- println!("ok: {:?}", status);- Ok(())- }),-);+// Count returns a Status if the key is under the limit and an `Error::LimitExceeded`+// containing a Status if the limit has been exceeded+match limiter.count(key).await {+ // In this case we are under the limit and can print out the limit status to the+ // standard output stream+ Ok(status) => println!("ok: {:?}", status),+ // This example deals with both limit exceeded and any Redis connection issues. In this+ // case we'll print the error to the standard error stream to show the current limit+ // status+ Err(err) => eprintln!("err: {}", err),+} ``` ### The Limiter Builder@@ -11,8 +11,8 @@ //! the backend is performing in a non-blocking, asynchronous fashion allowing the library to pair //! with other async frameworks such as Tokio, Actix, etc. //!-//! *Note*: Currently pre-*async/await* Futures are used (that is Futures 0.1.x) but that may be-//! upgraded in the near future as the Rust 1.39.0 release is near.+//! [`Limiter::count`] is an `async fn`, so it needs an async runtime (such as Tokio or Actix) to+//! drive it. //! //! # Usage //!@@ -27,7 +27,7 @@ //! //! The primary type is the [`Limiter`] which uses a builder to construct itself. Once built, use //! the [`count`] method with a key representing a user, a session, an interaction, etc. Note that-//! `count` is a Future and therefore has to be driving to completion with a runtime. For example,+//! `count` is async and therefore has to be driven to completion by a runtime. For example, //! to run one count on a key of `"10.0.0.5"`: //! //! [`Limiter`]: struct.Limiter.html@@ -35,35 +35,26 @@ //! //! ```no_run //! use limitation::Limiter;-//! use futures::Future; //!+//! # async fn example() -> Result<(), limitation::Error> { //! // Build a Limiter with a default rate with a local running Redis instance //! let limiter = Limiter::build("redis://127.0.0.1/").finish()?; //! // The key to count and track //! let key = "10.0.0.5"; //!-//! // TODO(bt,2023-12-12): This doctest is so far behind in `futures` versions and needs to be updated.-//! // Tokio should be executing the future and evaluating the result.-//! // Start and run a Tokio runtime to drive the Future to completion-//! //let mut rt = tokio::runtime::Runtime::new().unwrap();-//! //rt.block_on(...)//!-//! let _r = limiter-//! // Count returns a Status if the key is under the limit and an `Error::LimitExceeded`-//! // containing a Status if the limit has been exceeded-//! .count(key)-//! // This example deals with both limit exceeded and any Redis connection issues. In this-//! // case we'll print the error to the standard error stream to show the current limit-//! // status-//! .map_err(|err| eprintln!("err: {}", err))-//! // In this case we are under the limit and can print out the limit status to the-//! // standard output stream-//! .and_then(|status| {-//! println!("ok: {:?}", status);-//! Ok(())-//! })-//! .wait();-//! //);-//! # Ok::<(), limitation::Error>(())+//! // Count returns a Status if the key is under the limit and an `Error::LimitExceeded`+//! // containing a Status if the limit has been exceeded+//! match limiter.count(key).await {+//! // In this case we are under the limit and can print out the limit status to the+//! // standard output stream+//! Ok(status) => println!("ok: {:?}", status),+//! // This example deals with both limit exceeded and any Redis connection issues. In this+//! // case we'll print the error to the standard error stream to show the current limit+//! // status+//! Err(err) => eprintln!("err: {}", err),+//! }+//! # Ok(())+//! # } //! ``` //! //! ## The Limiter Builder