[harmseru]

Fixes #1282.

REDIS_TIMEOUT/REDIS_PERSECOND_TIMEOUT are documented as covering "Redis connection and I/O operations", but createDialer() only ever threads the configured value into net.Dialer.Timeout, which bounds Dial() alone. No deadline is attached to any Do()/pipeline call anywhere in the service, so the documented I/O timeout has never actually applied to I/O — see #1282 for the full writeup and the production impact (a single silently-dead Redis connection, caused in our case by a CNI dropping the underlying NAT/conntrack entry with no FIN/RST, blocked its goroutine forever and leaked every caller queued behind it for a pool slot, since the radix v4 pool is fixed-size and blocks when empty).

What this changes

Adds deadlineEnforcingClient in src/redis/driver_impl.go, which wraps the radix client returned from newClientImpl so every Do() call is bounded by the existing REDIS_TIMEOUT/REDIS_PERSECOND_TIMEOUT value:

• only applies the timeout when the caller's context has no deadline, or a looser one — never widens a caller's own tighter deadline
• skipped entirely when the configured timeout is <= 0, preserving today's unbounded behavior as an explicit opt-out
• applies to both the main and per-second Redis clients, since both go through newClientImpl

No new config surface. This makes the existing, already-documented setting do what it says.

I verified against radix/v4 v4.1.4 that this is sufficient on its own: conn.EncodeDecode and Pool.Do already select on ctx.Done() — EncodeDecode force-unblocks a pending read via SetReadDeadline and marks the connection unusable so the pool discards/redials it, and Pool.Do aborts while still queued for a connection if the context is done first. So no change is needed in radix itself.

Compatibility note

This is technically a behavior change: a Do() call that previously could block forever on a dead connection will now return an error after REDIS_TIMEOUT (default 10s). Anyone who wants to keep the old unbounded behavior can set REDIS_TIMEOUT=0 / REDIS_PERSECOND_TIMEOUT=0.

Test plan

• New tests in src/redis/driver_impl_test.go: a stuck call gets bounded by ioTimeout instead of hanging, an existing tighter caller deadline is respected rather than widened, the <=0 opt-out returns the original client unchanged, and a normal fast call is unaffected.
• go test ./src/redis/..., go vet ./src/redis/..., gofmt -l, and pre-commit run -a all pass.

/cc @mattklein123 @ysawa0

[harmseru]

Closing in favor of #1271, which was already open before we filed this and addresses the same root cause more completely.

Our fix here bounded Do() with a context deadline at the call site, which stops the caller from hanging forever but doesn't actually fix the pool: conn.go's doRead() translates a context-deadline error into resp.ErrConnUsable, so radix puts the dead connection back in the pool instead of closing it — the next caller just times out again, with no self-healing. It also doesn't bound write-side stalls.

#1271 avoids both problems by wrapping the underlying net.Conn and distinguishing its own liveness-deadline errors from genuine caller-context cancellations, so radix correctly closes and replaces a dead connection rather than recycling it, and both reads and writes are bounded. Left a comment there with production metrics corroborating the failure mode. Would recommend prioritizing that one instead.