We're using nextjs-turbo-redis-cache in production with a versioned cache strategy. On each deployment, we change the
keyPrefix to include the build number, which effectively starts a fresh cache for the new build:

cachedHandler = new RedisStringsHandler({
  keyPrefix: `nextjs:${buildId}`, // buildId changes on each deployment
  // ... other config
});

While this setup works correctly, we encounter verbose error logging that makes it difficult to identify actual issues.

Current Behavior:

When a new deployment goes live, every first access to a cache key (which doesn't exist yet) throws/logs an error. Since we're
starting with an empty cache, this results in hundreds or thousands of "cache not found" errors flooding our logs, making it
hard to spot genuine problems.

Expected Behavior:

A cache miss on the first access to a key should be treated as expected behavior, not as an error. The library should either:

1. Silently return null for cache misses without throwing exceptions (preferred approach - let the consumer decide how to log)
2. Log cache misses at info/debug level instead of error level
3. Distinguish between cache misses and actual errors (connection failures, timeouts, etc.) in the exception type

Suggested Solution:

Consider implementing something like:

• Return null for cache misses without throwing
• Add a silent or logLevel option to control logging verbosity

This would allow users to handle cache misses gracefully without noise in production logs, while still catching real Redis
connectivity or configuration issues.