fix(redis): honour caller deadline in k8s Provision — stop pro-tier provision hang

[mastermanas805]

Symptom

Provisioning a Redis cache for an authenticated Pro/Team team hangs (>60s, never returns), while the anonymous cache provision returns in ~6s.

• anonymous → teamID="", tier="anonymous" → FAST (~6s)
• authed pro → teamID=<uuid>, tier="pro" → HANGS

Root cause (file:line)

internal/backend/redis/k8s.go K8sBackend.Provision derived its provisioning context from context.Background() with a hardcoded 5-minute timeout, completely discarding the incoming gRPC ctx:

// OLD
provCtx, provCancel := context.WithTimeout(context.Background(), 5*time.Minute)

Why only the pro/team path hits it:

• Pro/Team Redis uses a real 10Gi PVC (pvcMi=10240, sizingForTier). When the DOKS block-storage attach / PVC bind stalls (CSI stuck, slow attach, quota), the pod never reaches Ready and waitPodReady polls for the full redisK8sReadyTO (3 min).
• Anonymous uses pvcMi=0 → emptyDir, which skips the 5–10s volume attach, so the pod is Ready in seconds — the slow-attach path is never exercised.

Because the wait used a background-derived context, even after the api's gRPC ProvisionCache deadline (cacheProvisionTimeout = 45s, already shipped api-side) fired and gRPC cancelled the server ctx, the provisioner ignored the cancellation and kept blocking the handler for up to 5 minutes — and left a half-built namespace behind, since the cancellation never reached the rollback path. From the api's side: an unbounded hang plus a resource leak.

Fix

• provisionContext() derives provCtx from the incoming ctx (so the api's deadline/cancellation propagates) while still imposing a hard server-side ceiling redisK8sProvisionCeiling (5m) for callers with no deadline. Effective wait = min(caller deadline, redisK8sReadyTO, ceiling).
• waitPodReady checks ctx.Err() at the top of each poll and wraps cancellation in a clear, mappable error.
• rollback now deletes the half-built namespace via a fresh 30s background ctx so cleanup still runs even when the incoming ctx is already cancelled (no namespace leak on timeout).
• mapError classifies context.DeadlineExceeded / context.Canceled via errors.Is (not a fragile substring) → retryable gRPC status (DeadlineExceeded / Unavailable), so the api soft-deletes + 503s rather than returning a hard 500.

A timed-out/cancelled provision now returns a clean gRPC error promptly and rolls back, never hangs — complementary to the api-side 45s cacheProvisionTimeout.

Tests

internal/backend/redis/k8s_test.go:

• TestProvision_ProTier_HonoursCallerDeadline — core regression guard: fake clientset whose pod never goes Ready (simulates stalled PVC attach); asserts Provision returns in <30s wrapping context.DeadlineExceeded, not after redisK8sReadyTO (3m). Reverting to a background context fails this test.
• TestProvision_AnonTier_HonoursCallerDeadline
• TestProvision_CallerCancel_FastFails
• TestProvisionContext_HonoursCallerDeadline / TestProvisionContext_CeilingBoundsNoDeadlineCaller

internal/server/maperror_test.go:

• TestMapError_ContextErrors_AreRetryable — wrapped + bare context errors map to retryable statuses.

Local gate

make gate equivalent green:

• go build ./... ✅
• go vet ./... ✅
• go test ./... -short -count=1 ✅ (all packages OK)

New Provision tests fast-fail in ~0.2–0.3s, confirming the caller deadline is honoured.

Scope note

The same context.Background() provision anti-pattern exists in the postgres and mongo k8s backends. This PR fixes only the redis path (the reported symptom). The postgres/mongo paths are bounded api-side by their own longer provisionTimeout(tier) and were not reported as hanging; left for a focused follow-up to keep this PR tight.

🤖 Generated with Claude Code