… default config compatible with current RESP2 shape. Adding possibility to opt-in for unified responses for both protocol. (#4052)

* Revert "Changing the default RESP protocol configurations for Redis clients and connections to 3 (#4031)"

This reverts commit 0984334.

* Revert "RESP2 and RESP3 response unification (#4025)"

This reverts commit de8a47a.

* Fixing newly added test to be compatible with the old style responses

* Default to RESP3 wire protocol, add legacy_responses opt-out

The default RESP protocol on the wire is now RESP3 (was RESP2). To keep
existing applications working unchanged, response shapes still match
today's RESP2-style Python objects by default, controlled by a new
legacy_responses=True parameter on the public clients.

* redis/utils.py
  - DEFAULT_RESP_VERSION lives here (moved from redis.connection) and is
    set to 3
  - check_protocol_version() resolves protocol=None to
    DEFAULT_RESP_VERSION before comparison, so a missing protocol is
    treated as RESP3-capable

* redis/connection.py, redis/asyncio/connection.py
  - import DEFAULT_RESP_VERSION from redis.utils (still re-exported from
    redis.connection for backward compatibility)
  - AbstractConnection.__init__: protocol default 2 -> None, new
    legacy_responses: bool = True stored as self.legacy_responses
  - URL_QUERY_ARGUMENT_PARSERS accepts protocol and
    legacy_responses, so both can be passed in connection URLs via
    redis://...?protocol=3&legacy_responses=false

* redis/client.py, redis/asyncio/client.py
  - Redis.__init__: protocol default 2 -> None, new legacy_responses
    parameter, both forwarded into the connection pool kwargs
  - client-side caching and maintenance-notifications gating switched
    to check_protocol_version(...) so a missing protocol is treated
    as RESP3

* redis/asyncio/cluster.py
  - RedisCluster.__init__: protocol default 2 -> None, new
    legacy_responses parameter, both placed in the cluster connection
    kwargs

* redis/cluster.py
  - REDIS_ALLOWED_KEYS includes legacy_responses so it propagates
    through cleanup_kwargs() to per-node Redis instances

A user-supplied protocol=None is preserved on the pool / connection
kwargs; only the wire-level HELLO handshake resolves it to the concrete
DEFAULT_RESP_VERSION.

* Adding test fixes

* Adding changes for first several commands and test helpers

* Adding changes for batches 5 and 6

* Adding the rest of the base commands.

* Adding changes for probabilistic and timeseries modules

* Adding changes for search and json modules. Adding docs and test fixes. Updating some of the unified forms to the correct ones

* Adding test_xreadgroup_with_claim_min_idle_time fix

* Adding pipeline test coverage for all combinations of protocol and legacy_responses

* Applying review comments

* Applying review comments

* Applying review comments and fixing failing tests

* Applying review comments and fixing failing tests

* Add flaky test fix

* Add flaky test fix- second try, same test - fails for just one job

* Fixing unstable in CI tests

* Applying review comments

* Fixing linters and spelling error

* Applying review comments

## Issue

The vector set Python tests intentionally use two clients: 
- the default client (`self.redis`) for the existing RESP2-oriented test
expectations
- `self.redis3` for RESP3-specific coverage.

However, the default client did not explicitly set a protocol, so it
depended on redis-py's default behavior. With newer redis-py versions,
RESP3 is now the default
protocol(redis/redis-py#4052). In particular,
vector set replies such as `VSIM ... WITHSCORES` may be parsed into
map/dict-like structures instead of the RESP2 flat-array shape assumed
by existing tests.

## Changes

Explicitly create the default primary and replica Redis clients with
`protocol=2`.
`self.redis3` is left unchanged and continues to use `protocol=3` for
RESP3-specific test coverage.

## Issue

The vector set Python tests intentionally use two clients:
- the default client (`self.redis`) for the existing RESP2-oriented test
expectations
- `self.redis3` for RESP3-specific coverage.

However, the default client did not explicitly set a protocol, so it
depended on redis-py's default behavior. With newer redis-py versions,
RESP3 is now the default
protocol(redis/redis-py#4052). In particular,
vector set replies such as `VSIM ... WITHSCORES` may be parsed into
map/dict-like structures instead of the RESP2 flat-array shape assumed
by existing tests.

## Changes

Explicitly create the default primary and replica Redis clients with
`protocol=2`.
`self.redis3` is left unchanged and continues to use `protocol=3` for
RESP3-specific test coverage.

(cherry picked from commit 8fcf3dc)

## Issue

The vector set Python tests intentionally use two clients:
- the default client (`self.redis`) for the existing RESP2-oriented test
expectations
- `self.redis3` for RESP3-specific coverage.

However, the default client did not explicitly set a protocol, so it
depended on redis-py's default behavior. With newer redis-py versions,
RESP3 is now the default
protocol(redis/redis-py#4052). In particular,
vector set replies such as `VSIM ... WITHSCORES` may be parsed into
map/dict-like structures instead of the RESP2 flat-array shape assumed
by existing tests.

## Changes

Explicitly create the default primary and replica Redis clients with
`protocol=2`.
`self.redis3` is left unchanged and continues to use `protocol=3` for
RESP3-specific test coverage.

(cherry picked from commit 8fcf3dc)

…4109)

* fix(search): parse RESP3 FT.SEARCH responses with bytes-typed keys

Since the wire protocol default switched to RESP3 (#4052), the server
returns FT.SEARCH responses as RESP3 maps.  When a client is opened with
``decode_responses=False`` the map keys arrive as ``bytes`` rather than
``str``, but ``Result.from_resp3`` looked them up as plain strings:

    instance.total = res.get("total_results", 0)
    for result_item in res.get("results", []):
        ...

Because ``b"total_results" != "total_results"``, every lookup missed and
the search appeared to return ``Result{0 total, docs: []}`` even though
the server had matched documents.

Normalise the top-level map and each per-result map to string keys
before reading them, mirroring the pattern already used by
``_parse_hybrid_search_resp3`` in ``redis/commands/search/commands.py``
("Top-level keys are normalised to strings").

Adds ``tests/test_search_result.py`` with regression tests covering
str-keyed, bytes-keyed, and mixed maps, plus the empty/None edge cases.
The tests fail on the unfixed code for the bytes and mixed cases.

Fixes #4107

* fix(search): extend bytes-key normalisation to AGGREGATE and SPELLCHECK

The RESP3 callbacks for FT.SEARCH (`Result.from_resp3`) were taught to
normalise top-level structural map keys to strings so that responses
parsed correctly on connections opened with `decode_responses=False`.
`_parse_aggregate_resp3` (FT.AGGREGATE / FT.CURSOR READ /
FT.PROFILE AGGREGATE) and `_parse_spellcheck_resp3` (FT.SPELLCHECK)
still read `"total_results"`, `"results"` and `"warning"` as
plain strings, so a byte-keyed RESP3 response missed every lookup and
silently parsed as an empty AggregateResult / `{}` even when the
server had returned data.

Apply the same `str_if_bytes` normalisation that
`Result.from_resp3` and `_parse_hybrid_search_resp3` already use:

- normalise the top-level map and (for aggregate) the per-result-item
  map; document data inside `extra_attributes` is left as-is so the
  caller still sees bytes when `decode_responses=False`, mirroring the
  RESP2 shape;
- normalise the outer `results` key for spellcheck; the inner term keys
  match the RESP2 `decode_responses=False` shape and stay as bytes.

Adds regression tests for both parsers in
`tests/test_search_result.py`, plus integration tests in
`tests/test_search.py` that exercise the three affected Search
callbacks (FT.SEARCH, FT.AGGREGATE, FT.SPELLCHECK) against a real
RESP3 wire with a `decode_responses=False` client.

* fix(search): apply petyaslavova review feedback

- _parse_spellcheck_resp3 now preserves the suggestion value as-is so
  it keeps the decode_responses shape RESP2 would produce (str when
  decoded, bytes otherwise) instead of wrapping bytes in str().
- waitForIndex now accepts both str and bytes structural keys in
  FT.INFO responses.  execute_command bypasses the search module's
  callbacks, so the helper has to handle the raw RESP3 dict/RESP2
  list shapes for decode_responses=False clients.  This unblocks the
  previously failing fixed-clients CI matrix entry.
- The bytes-keys integration tests are now parametrised over
  protocol=2 (anchors the legacy output shape) and the default
  protocol (the path that actually exercises the changed parsers in
  _RedisCallbacksRESP3toRESP2Legacy).  Explicit protocol=3 was
  routing through _RedisCallbacksRESP3 and bypassing the fix.
- Spellcheck assertion is stricter: it pins the term key to
  b"impornant" and the suggestion value to b"important".
- Mirror the suggestion-bytes assertion in the
  test_search_result.py unit test.

* test(search): tidy review nits in RESP3 bytes-key tests

- Rephrase the parametrisation comment so it explains *why* the two
  protocol arms exist in terms of the parsers being exercised
  (_parse_search_resp3 / _parse_aggregate_resp3 /
  _parse_spellcheck_resp3) rather than "the changed methods", which
  was only meaningful relative to this PR's diff.
- Reorder decorators on TestSearchResp3BytesKeys methods so the
  test-scope marks (redismod, fixed_client) stay grouped and
  @pytest.mark.parametrize sits last, matching the prevailing style
  for parametrised tests.

---------

Co-authored-by: petyaslavova <[email protected]>

…4109)

* fix(search): parse RESP3 FT.SEARCH responses with bytes-typed keys

Since the wire protocol default switched to RESP3 (#4052), the server
returns FT.SEARCH responses as RESP3 maps.  When a client is opened with
``decode_responses=False`` the map keys arrive as ``bytes`` rather than
``str``, but ``Result.from_resp3`` looked them up as plain strings:

    instance.total = res.get("total_results", 0)
    for result_item in res.get("results", []):
        ...

Because ``b"total_results" != "total_results"``, every lookup missed and
the search appeared to return ``Result{0 total, docs: []}`` even though
the server had matched documents.

Normalise the top-level map and each per-result map to string keys
before reading them, mirroring the pattern already used by
``_parse_hybrid_search_resp3`` in ``redis/commands/search/commands.py``
("Top-level keys are normalised to strings").

Adds ``tests/test_search_result.py`` with regression tests covering
str-keyed, bytes-keyed, and mixed maps, plus the empty/None edge cases.
The tests fail on the unfixed code for the bytes and mixed cases.

Fixes #4107

* fix(search): extend bytes-key normalisation to AGGREGATE and SPELLCHECK

The RESP3 callbacks for FT.SEARCH (`Result.from_resp3`) were taught to
normalise top-level structural map keys to strings so that responses
parsed correctly on connections opened with `decode_responses=False`.
`_parse_aggregate_resp3` (FT.AGGREGATE / FT.CURSOR READ /
FT.PROFILE AGGREGATE) and `_parse_spellcheck_resp3` (FT.SPELLCHECK)
still read `"total_results"`, `"results"` and `"warning"` as
plain strings, so a byte-keyed RESP3 response missed every lookup and
silently parsed as an empty AggregateResult / `{}` even when the
server had returned data.

Apply the same `str_if_bytes` normalisation that
`Result.from_resp3` and `_parse_hybrid_search_resp3` already use:

- normalise the top-level map and (for aggregate) the per-result-item
  map; document data inside `extra_attributes` is left as-is so the
  caller still sees bytes when `decode_responses=False`, mirroring the
  RESP2 shape;
- normalise the outer `results` key for spellcheck; the inner term keys
  match the RESP2 `decode_responses=False` shape and stay as bytes.

Adds regression tests for both parsers in
`tests/test_search_result.py`, plus integration tests in
`tests/test_search.py` that exercise the three affected Search
callbacks (FT.SEARCH, FT.AGGREGATE, FT.SPELLCHECK) against a real
RESP3 wire with a `decode_responses=False` client.

* fix(search): apply petyaslavova review feedback

- _parse_spellcheck_resp3 now preserves the suggestion value as-is so
  it keeps the decode_responses shape RESP2 would produce (str when
  decoded, bytes otherwise) instead of wrapping bytes in str().
- waitForIndex now accepts both str and bytes structural keys in
  FT.INFO responses.  execute_command bypasses the search module's
  callbacks, so the helper has to handle the raw RESP3 dict/RESP2
  list shapes for decode_responses=False clients.  This unblocks the
  previously failing fixed-clients CI matrix entry.
- The bytes-keys integration tests are now parametrised over
  protocol=2 (anchors the legacy output shape) and the default
  protocol (the path that actually exercises the changed parsers in
  _RedisCallbacksRESP3toRESP2Legacy).  Explicit protocol=3 was
  routing through _RedisCallbacksRESP3 and bypassing the fix.
- Spellcheck assertion is stricter: it pins the term key to
  b"impornant" and the suggestion value to b"important".
- Mirror the suggestion-bytes assertion in the
  test_search_result.py unit test.

* test(search): tidy review nits in RESP3 bytes-key tests

- Rephrase the parametrisation comment so it explains *why* the two
  protocol arms exist in terms of the parsers being exercised
  (_parse_search_resp3 / _parse_aggregate_resp3 /
  _parse_spellcheck_resp3) rather than "the changed methods", which
  was only meaningful relative to this PR's diff.
- Reorder decorators on TestSearchResp3BytesKeys methods so the
  test-scope marks (redismod, fixed_client) stay grouped and
  @pytest.mark.parametrize sits last, matching the prevailing style
  for parametrised tests.

---------

Co-authored-by: petyaslavova <[email protected]>