That's pretty surprising! It does indeed seem like there's an issue here with the <RedisConnectionManager as ManageConnection>::is_valid(), but I'm pretty confused that the call to PING and awaiting its result wouldn't take care of the PONG response. Can you produce a minimal reproduction of the issue?

I noticed this in the Redis docs:

If the client is subscribed to a channel or a pattern, it will instead return a multi-bulk with a "pong" in the first position and an empty bulk in the second position, unless an argument is provided in which case it returns a copy of the argument.

Is your client subscribed to a channel or pattern?

(Note that you don't need to bump the tokio dependency to 1.1 in the bb8 dependencies explicitly, since 1.1 is semver-compatible with 1.0. You can just use tokio 1.1 in your downstream dependency/application, and bb8 should pick it up.)

Any chance it may be connected with redis-rs/redis-rs#308 ?

Also we can have a look how it is implemented in mobc: https://github.com/importcjj/mobc/blob/87ae0152a51c0526caee9bd87455acf20cc778cb/mobc-redis/src/lib.rs#L30

Is your client subscribed to a channel or pattern?

no, we don't

@invis87 maybe you can try with the explicit return type as suggested in redis-rs/redis-rs#308?

@djc I already have it: let response: redis::RedisResult<collections::HashMap<String, String>> = conn.hgetall(key).await;

I meant in the ConnectionManager::is_valid() code.

I don't know how to reproduce that bug. Sometimes service "moved to buggy state" and then there are a lot of Response was of incompatible type: "Response type not hashmap compatible" (response was status("PONG")) until restart, but usually it works fine.
Looks like I need to wait for that state to appear and then trying to catch the problem with gdb.

Buuut, I will try to fix ConnectionManager::is_valid() anyway :)

Hmmm, interesting!
With those dependencies:

bb8 = "0.7.0"
bb8-redis = "0.8.1"

Service still have response was status("PONG") errors - much less then with version without fix, but still.

On the other hand, with deps:

bb8 = { git = "https://github.com/invis87/bb8.git", branch = "fix_ping_request" }
bb8-redis = { git = "https://github.com/invis87/bb8.git", branch = "fix_ping_request" }

Number if errors is zero.

That is surprising. Did you correct for other differences in the Cargo.lock file?

Hmmm, after night response was status("PONG") appears on mine version too... I think it is less of them, but still.

Here is the diff:

 [[package]]
 name = "bb8"
-version = "0.7.0"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "dae93eccab998c4b8703e3a6bbaa1714c38e445ebacb4bede25d0408521e293c"
+version = "0.8.0"
+source = "git+https://github.com/invis87/bb8.git?branch=fix_ping_request#5a38f008d11f2467b44d469d69e0a31a7fdf618d"
 dependencies = [
  "async-trait",
  "futures-channel",
@@ -100,9 +99,8 @@ dependencies = [

 [[package]]
 name = "bb8-redis"
-version = "0.8.1"
-source = "registry+https://github.com/rust-lang/crates.io-index"
-checksum = "8a77bf264e0442cbf0644595e64f1f8e15f1e5fe99c9d0959072e54ffbd2b9d5"
+version = "0.9.0"
+source = "git+https://github.com/invis87/bb8.git?branch=fix_ping_request#5a38f008d11f2467b44d469d69e0a31a7fdf618d"
 dependencies = [
  "async-trait",
  "bb8",

Am I the only one who use hgetall with bb8-redis? Problem appears only here:

    let response: redis::RedisResult<collections::HashMap<String, String>> =
        conn.hgetall(key).await;

@djc look what Ive found: importcjj/mobc#28

Yeah, I'm guessing this is actually due to redis-rs/redis-rs#325 and bb8 is actually not causing this.

@djc A workaround would be using get_multiplexed_async_connection instead of get_async_connection, would you accept a PR for this?

As the semantics are not the same maybe this should be done through a feature flag or an other adapter?

@Barre I think that would make sense. Please submit it without a feature flag first, and explain a bit more in the PR about any changes in the semantics that you expect/are documented.