Summary

The publisher, rate limit and lock adapters used different units and shapes for similar options. This PR fixes three inconsistencies:

• The publisher's resume.seconds was in seconds, while every lock and rate-limit timing is in milliseconds.
• Waiting was a flat timeout on the lock but blockingUntilReady: { enabled, timeout } on the rate limiter.
• UpstashRateLimiter took an @upstash/ratelimit instance, while UpstashPublisher and UpstashLocker take a Redis client.

Breaking changes

Publisher retention is in milliseconds

resume.seconds is now resume.ttl, in milliseconds (default 300000). This applies to MemoryPublisher, RedisPublisher, UpstashPublisher and BunRedisPublisher.

// Before
new RedisPublisher(client, { resume: { enabled: true, seconds: 300 } })

// After
new RedisPublisher(client, { resume: { enabled: true, ttl: 300_000 } })

DurablePublisherObject (@orpc/cloudflare) changed the same way: seconds is now ttl, and cleanupIntervalSeconds is now cleanupInterval, both in milliseconds.

// Before
super(ctx, env, { resume: { enabled: true, seconds: 300, cleanupIntervalSeconds: 6 * 60 * 60 } })

// After
super(ctx, env, { resume: { enabled: true, ttl: 300_000, cleanupInterval: 6 * 60 * 60 * 1000 } })

Rate limiters take a flat timeout

blockingUntilReady: { enabled, timeout } is now timeout, matching the lock. The default is 0 (don't wait), so default behavior is unchanged. This applies to MemoryRateLimiter, RedisRateLimiter, UpstashRateLimiter and BunRedisRateLimiter.

// Before
new MemoryRateLimiter({ maxRequests: 10, window: 60_000, blockingUntilReady: { enabled: true, timeout: 5000 } })

// After
new MemoryRateLimiter({ maxRequests: 10, window: 60_000, timeout: 5000 })

As before, a request gives up right away when its window will not reset before the timeout.

UpstashRateLimiter takes a Redis client

UpstashRateLimiter now extends BaseRedisRateLimiter, like RedisRateLimiter and BunRedisRateLimiter, and shares counters with them.

// Before
const ratelimit = new Ratelimit({ redis, limiter: Ratelimit.slidingWindow(10, '60 s') })
new UpstashRateLimiter(ratelimit, { blockingUntilReady: { enabled: true, timeout: 5000 } })

// After
new UpstashRateLimiter(Redis.fromEnv(), { maxRequests: 10, window: 60_000, timeout: 5000 })

• Removed: the @upstash/ratelimit peer dependency (@upstash/redis replaces it) and the waitUntil option.
• Lost features: only a fixed window is supported now. Upstash's other algorithms (sliding window, token bucket), multi-region support and analytics are gone.
• Workaround: users who need those can wrap a Ratelimit instance in a small custom RateLimiter.

Other changes

• Rate limiter internals: the memory and Redis rate limiters now share one internal wait loop and weight check (packages/ratelimit/src/utils.ts).
• Shared resume type: publishers share one exported PublisherResumeOptions type, which DurablePublisherObjectResumeOptions extends.
• Redis stream expiry: Redis-backed publishers now set the stream expiry with PEXPIRE (ms) instead of EXPIRE (s).
• Durable Object storage: the SQLite stored_at column stays in seconds, and the code converts ttl at cleanup. Existing tables keep their old column default, so switching the column to milliseconds would delete every stored event.
• | undefined convention: new optional fields are declared as X | undefined, following fix: accept explicit undefined on optional option fields #2278.
• Docs: the publisher and rate limit pages use the new options. The v1 migration guide now maps resumeRetentionSeconds/retentionSeconds to ttl, blockingUntilReady to timeout, and shows a before/after for the Upstash rate limiter.

Verification

• Static checks: pnpm lint, pnpm type:check and pnpm docs:validate pass.
• Redis integration tests: the publisher, rate limit and lock tests pass against a local Redis, including the stream-expiry test that now uses PEXPIRE.
• Bun and Cloudflare: bun test in packages/bun passes against local Redis (136 pass, 6 skip). The Cloudflare workerd tests pass (74).
• Not run: the Upstash tests need Upstash credentials. I rewrote the Upstash rate limiter test against a Redis client. Separately, I ran UpstashRateLimiter against local Redis through a stand-in for the Upstash client's eval. It shared counters with RedisRateLimiter and waited and gave up as expected. That does not cover a real Upstash server.

Generated by Claude Code