mirror of
https://github.com/redis/redis.git
synced 2026-07-16 13:32:51 -04:00
5b5c32663b
Some checks are pending
CI / test-ubuntu-latest (push) Waiting to run
CI / test-sanitizer-address (push) Waiting to run
CI / build-debian-old (push) Waiting to run
CI / build-macos-latest (push) Waiting to run
CI / build-32bit (push) Waiting to run
CI / build-libc-malloc (push) Waiting to run
CI / build-centos-jemalloc (push) Waiting to run
CI / build-old-chain-jemalloc (push) Waiting to run
Codecov / code-coverage (push) Waiting to run
External Server Tests / test-external-standalone (push) Waiting to run
External Server Tests / test-external-cluster (push) Waiting to run
External Server Tests / test-external-nodebug (push) Waiting to run
Spellcheck / Spellcheck (push) Waiting to run
## Issue
The `XREAD MAXSIZE budget is per-command inside MULTI/EXEC` test compares the
entry count of a standalone `XREAD` reply against the same `XREAD` issued inside
a `MULTI`/`EXEC`. Under `--force-resp3` the test client's RESP3→RESP2
`transform_response_if_needed` dispatcher keys only on the command actually
sent, so it transforms the standalone `XREAD` reply but leaves the `EXEC` reply
and its nested sub-replies untouched. The standalone reply therefore arrives in
RESP2 array-of-pairs shape (`{{stream {entries...}}}`) while the EXEC-nested
`XREAD` reply stays in RESP3 map shape (`{stream {entries...}}`), causing
`xread_total_entries` to count `22` versus `2` and the assertion to fail only
under `--force-resp3`, even though both replies are functionally correct.
## Change
Normalize the nested `XREAD` reply from `EXEC` when running with
`--force-resp3`, so the test compares the same RESP2-style structure for
both the standalone and transactional `XREAD` replies.
|
||
|---|---|---|
| .. | ||
| array.tcl | ||
| hash-field-expire.tcl | ||
| hash.tcl | ||
| incr.tcl | ||
| increx.tcl | ||
| list-2.tcl | ||
| list-3.tcl | ||
| list.tcl | ||
| set.tcl | ||
| stream-cgroups.tcl | ||
| stream.tcl | ||
| string.tcl | ||
| zset.tcl | ||