Middleware: parallelize/pipeline 2 Redis hot paths

2026-05-07

apimiddlewareredisagent-reputation

What We Built

Two Redis hot paths converted from serial to parallel/pipelined. (1) getReputation() made 2 serial Redis GETs on cold-start (loadReputationFromRedis then loadHistoryFromRedis); both independent reads. Parallelized via Promise.all. (2) incrementAgentRate did await redis.incr(key) then conditional await redis.expire(key, 60) — 2 serial round-trips. Pipelined into a single call. Bonus: dropped the count===1 conditional since EXPIRE is idempotent.

Why It Matters

Both paths fire on the rate-limit middleware's hot path. In a 2-task ECS fleet, requests alternate tasks so an agent's in-memory cache is cold ~50% of the time.

How It Works

Regression tests assert (a) both Redis GETs in getReputation start within 20ms of each other (overlap test), (b) pipeline is invoked with both ops batched, (c) EXPIRE set on every call (idempotent test).

Lockstep Checklist

[x] No API route changes (middleware/internal — lockstep N/A)
[x] No SDK changes
[x] No MCP tool changes
[x] Regression test included (test-first invariant per /quality-fleet protocol)
[x] Linked to /quality-fleet R1 dashboard at .quality/dashboard.md

Provenance

Auto-found by /quality-fleet R1 (2026-05-07) scanner round, fixed in fix-agent batch under "go for all of it" autonomy grant. PR #214 merged to main as commit 3e16a3461. Finding(s) tracked at .quality/findings.jsonl (entries: "f1c7b2a93e48", "d1b8e6c47a93"). Production-deployed via ECS task-def revision 732 series.