RESP3 default in 8.0 breaks connections to servers/proxies that don't support HELLO (no fallback)

[yangbodong22011]

Problem

redis-py 8.0 changed DEFAULT_RESP_VERSION from 2 to 3 (PR #4031). When connecting to a Redis server < 6.0 or a proxy that doesn't support the HELLO command, the connection fails immediately with ResponseError: unknown command — there is no automatic fallback to RESP2.

Root Cause

on_connect_check_health() in connection.py:1111-1114:

self.send_command("HELLO", self.protocol, "AUTH", *auth_args, check_health=False)
self.handshake_metadata = self.read_response()  # no try-except, raises directly

Unlike Lettuce, Jedis, and go-redis which catch HELLO failures and fall back to legacy AUTH, redis-py raises the error and the connection is never established.

Impact

Users upgrading from 7.x to 8.0 with zero code changes will experience immediate connection failures if their server/proxy doesn't support HELLO. This includes:

• Redis < 6.0
• Certain managed Redis proxies
• Third-party Redis-compatible services that haven't implemented HELLO

Suggested Fix

Catch ResponseError from the HELLO command and fall back to RESP2 + standalone AUTH, similar to what other clients do:

try:
    self.send_command("HELLO", self.protocol, "AUTH", *auth_args, check_health=False)
    self.handshake_metadata = self.read_response()
except ResponseError:
    # Server doesn't support HELLO, fall back to RESP2 AUTH
    if isinstance(self._parser, _RESP3Parser):
        self.set_parser(_RESP2Parser)
        self._parser.on_connect(self)
    self.protocol = 2
    self.send_command("AUTH", *auth_args, check_health=False)
    auth_response = self.read_response()
    if str_if_bytes(auth_response) != "OK":
        raise AuthenticationError("Invalid Username or Password")

Workaround

redis.Redis(host=host, port=port, password=password, protocol=2)

Explicitly setting protocol=2 avoids the HELLO path entirely.

[petyaslavova]

Hey @yangbodong22011, the latest library version is not claiming support for Redis versions < 6.0. In the README.md file, we have the following support matrix:

Library version	Supported redis versions
3.5.3	<= 6.2 Family of releases
>= 4.5.0	Version 5.0 to 7.0
>= 5.0.0	Version 5.0 to 7.4
>= 6.0.0	Version 7.2 to current

Also, we have reported this change in our release notes as breaking, and the workaround to force using RESP2 is provided there.
At this point, we don't have a plan to support a fallback mechanism.

[yangbodong22011]

Hi @petyaslavova, thanks for the clarification.

Is there a specific reason this had to be a breaking change rather than a backward-compatible upgrade? The impact is significant — many projects automatically pull the latest client version (e.g. 8.0 released yesterday), and this causes immediate startup failures without any code changes on the user's side.

The compatibility cost here is minimal (a try-except around the HELLO response), yet it would allow users to upgrade the client seamlessly. For reference, Lettuce, Jedis, and go-redis — all under the same redis/ org — implement this fallback today.

[petyaslavova]

Thanks for pushing on this, @yangbodong22011. I agree the current behavior can be a rough experience for users who upgrade and only then discover that their server or proxy does not support HELLO. At the same time, production systems should generally pin dependency versions, and major releases are where breaking changes can happen.

My main concern with a broad automatic fallback is that it hides the problem in a place where it is harder to debug. A failed HELLO followed by a retry means an extra network round trip on new connections to unsupported servers/proxies.
That kind of added connection latency is much harder to spot than a clear configuration error, and I believe we shouldn't optimize for automatic major-version upgrades at the cost of everyday connection behavior.

That said, I think fallback can make sense when the user is relying on the default redis-py configuration. In that case, we can fall back to RESP2 so affected users can continue using redis-py 8.0 while they either update their server/proxy or make the choice explicit with protocol=2. If we do this, we should also log a clear warning saying that the server/proxy does not support HELLO/RESP3, and that the user should either update the server/proxy or explicitly set protocol=2.

For cases where the user explicitly configured protocol=3, enabled client-side caching, or enabled maintenance notifications with enabled=True, I think we should raise an error instead of falling back. Those configurations either require RESP3 or strongly imply that the user asked for RESP3-specific behavior, and silently downgrading would be surprising.

So yes, I am open to fallback, but only for the default configuration path and with a useful warning. For explicit RESP3 or RESP3-dependent features, failing loudly is the better developer experience.