Silent Redis Failure in Rate Limiter — Fixed in v1.0.59

What happened

In src/lib/agent/rate-limiter.ts, the getRedis() helper was using a CommonJS dynamic require:

// ❌ Before — wrong Redis client
const redis = require('redis');

The redis npm package is not listed in package.json. Sidekick's declared dependency is ioredis. As a result, at runtime the require('redis') call failed silently and getRedis() returned null. The rate-limiter then fell back to its Postgres-only code path without logging a meaningful error, making the problem hard to detect.

The working-memory module in the same directory (src/lib/agent/working-memory.ts) already used ioredis correctly, so this was an inconsistency introduced specifically in the rate-limiter.

Why it matters

The rate-limiter is responsible for enforcing per-user and per-integration request quotas across all 100+ Sidekick connectors. Redis is the intended primary store for rate-limit counters because it provides:

• Atomic increment operations — avoids race conditions under high concurrency
• TTL-based key expiry — counters reset automatically without a background job
• Sub-millisecond latency — keeps overhead negligible on the hot path

Falling back to Postgres silently means:

• Higher latency on every agent action that checks a rate limit
• Potential for counter drift under concurrent requests (no atomic INCR)
• Postgres connection pool pressure from what should be in-memory operations

The fix

The getRedis() function in rate-limiter.ts has been updated to use ioredis, matching the pattern already established in working-memory.ts:

// ✅ After — consistent ioredis usage
import IORedis from 'ioredis';

function getRedis(): IORedis | null {
  if (!process.env.REDIS_URL) return null;
  return new IORedis(process.env.REDIS_URL);
}

No changes to calling code or rate-limit logic were required — only the client initialisation needed to be corrected.

Who is affected

All Sidekick deployments running v1.0.58 or earlier with a REDIS_URL configured were silently falling back to Postgres-only rate limiting. Deployments without Redis configured are unaffected (the null fallback is the intended behaviour in that case).

Upgrade

Update to v1.0.59. No configuration changes are needed. If REDIS_URL is set in your environment, the rate-limiter will automatically begin using Redis on next restart.