Skip to content

fix: cap cache durations at one year#96

Open
lan17 wants to merge 1 commit into
mainfrom
fix/issue-33-duration-limits
Open

fix: cap cache durations at one year#96
lan17 wants to merge 1 commit into
mainfrom
fix/issue-33-duration-limits

Conversation

@lan17

@lan17 lan17 commented Jul 26, 2026

Copy link
Copy Markdown
Owner

Summary

  • cap cache TTLs at 31,536,000 seconds (a fixed 365-day duration)
  • cap invalidation future buffers at 31,536,000,000 milliseconds
  • enforce the shared range in static defaults, dynamic policy resolution, cache conversion, high-level invalidation, and the exported Lua protocol
  • document the supported range and add exact boundary coverage

Why

DialCache previously accepted any positive safe-integer TTL even though local, Redis, tracked-watermark, and invalidation paths later multiplied or added those values independently. That made rejection timing inconsistent and allowed fallback serialization to happen before an oversized Redis TTL was rejected.

This change gives every duration path one simple supported maximum. Static/default TTLs reject before fallback work, malformed dynamic TTLs preserve the existing invalid_ttl fail-open behavior, and invalidations reject before Redis mutation. Existing inputs within 365 days are unchanged; larger inputs are now explicitly unsupported.

Validation

  • Node.js 22.22.0
  • corepack pnpm install --frozen-lockfile
  • corepack pnpm check (289 unit tests, typecheck, coverage, build, packed consumers)
  • corepack pnpm test:integration (77 Redis 6.2, Valkey 8, and Redis Cluster tests)
  • git diff --check

Closes #33

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Validate TTL and invalidation duration arithmetic consistently

1 participant