macOS arm64: fresh Redis RESP3 connections return EOF through published port; container-loopback control passes #776

Bug report

Bug description

Fresh RESP3 Redis connections intermittently fail with EOF through a Docker Desktop published port on macOS arm64 under connection churn. The identical standalone client, run sequentially via loopback inside the same Redis Software container, completes without failure. Please investigate the published-port networking path; these controls do not identify which component initiates termination and do not prove a Docker defect.

Preserved results — October 22, 2026

A client using only go-redis 9.23.0 and the Go standard library (no ADBC dependency) creates/closes one client per iteration, disables command retries, confirms RESP3, checks PING and a nil HGET on a synthetic absent key, and classifies failures:

Both used Go 1.26.10. Host failures occurred in the PING/setup phase; timeout, other-error, read-phase and close-failure counters were zero. Linux counters were all zero. Host exited 1; Linux exited 0. These are sequential runs, not simultaneous workloads.

Separate repeated SQL controls produced 184 passes / 16 EOF failures on the host and 200/200 passes inside Linux. Socket-lifecycle tracing on another SQL repeat saw all 73 EOF reads before local Close, with zero bytes received and 22 bytes written (initial HELLO 3). This is separate from the standalone control, not a correlated packet trace. An earlier 5,000-client control passed, so short probes may miss the issue.

Reproduction steps

1. Create a dedicated local three-shard Redis Software 8.6.2 fixture using the downstream repository's documented make -C go redis-up path. It configures and verifies active QPF 4x (six Search workers, mnp routing, 32 connections). Use an owned non-production fixture and a loopback published port. Our findings do not establish reproduction on Community Redis or other servers.
2. Set REDIS_URI privately to that fixture's loopback endpoint, database 0, without credentials/query parameters. The standalone probe validates that target shape; it performs no writes. Ensure the synthetic key named in the source does not exist.
3. At the pinned source below, run from the repository root:
   GOTOOLCHAIN=go1.26.10 go -C go run ../scripts/software_eof_client.go -count 50000
4. Sequentially cross-compile the same source with CGO_ENABLED=0, GOOS=linux and GOARCH=arm64. Copy the binary into the owned Software container, run with its loopback URI, then remove that exact copied binary. Do not run other tests against the fixture during comparison.
5. Compare the counts-only JSON output. The probe has a five-minute bound and exits nonzero for failure/incompletion. It confirms RESP3 explicitly and disables command retries.

Executable client:
https://github.com/alberttwong/redis-adbc-driver/blob/5486b3863c4e6ca2cadfdd9bea9fa9772b96cddc/scripts/software_eof_client.go

Evidence, matching host/Linux JSON, SQL comparison instructions and limits:
https://github.com/alberttwong/redis-adbc-driver/tree/5486b3863c4e6ca2cadfdd9bea9fa9772b96cddc/docs/sdlc/changes/software-eof-498

Downstream investigation: https://github.com/alberttwong/redis-adbc-driver/issues/498

Expected behavior and attribution limits

The published-port path should not introduce unexplained connection termination for the supported server/client protocol. We are requesting triage and guidance on payload-free, correlated networking diagnostics. The Linux control also changes client OS and scheduling, so it is not isolation of the Docker forwarding component alone. go-redis, host networking and the server proxy remain possible contributors. No native Linux-host reproduction or termination-initiator identification is claimed.

Server rejected-connection counters were zero in the SQL investigation. Tests did not add retries or weaken assertions. The fixture has been removed. This filing uses preserved completed runs; no new workload was executed to file it. Raw traces, credentials, license files, endpoints and operational identifiers are omitted.

Platform

macOS

Version information

Docker Desktop 4.96.2 (244353)
Docker Engine / client 29.9.2; API 1.56; context desktop-linux
Server linux/arm64, kernel 7.0.14-linuxkit
macOS 26.7.1 arm64
Go 1.26.10; go-redis 9.23.0
Redis Software with Redis 8.6.2, three shards, verified active QPF 4x
Docker version metadata checked at filing; workload evidence captured October 22, 2026. No raw docker info or diagnostic bundle attached.

Diagnostics ID

No response