Skip to content

Conversation

@busla
Copy link

@busla busla commented Jan 8, 2026

Summary

Adds a new REDIS_SINGLE_KEY_OPS configuration option to support AWS ElastiCache Serverless (Valkey 8.1) which internally shards data but doesn't expose the Redis Cluster protocol.

Problem

  • ElastiCache Serverless shards data across slots internally
  • Setting USE_REDIS_CLUSTER=false causes CROSSSLOT errors on batch operations
  • Setting USE_REDIS_CLUSTER=true fails with ClusterAllFailedError because ElastiCache Serverless doesn't support CLUSTER NODES/CLUSTER SLOTS commands

Solution

  • New REDIS_SINGLE_KEY_OPS env var forces single-key operations without requiring cluster client
  • Decouples operation style (batch vs individual) from client type (single-node vs cluster)
  • For ElastiCache Serverless: use USE_REDIS_CLUSTER=false + REDIS_SINGLE_KEY_OPS=true

Change Type

  • New feature (non-breaking change which adds functionality)

Testing

  1. Set USE_REDIS=true, USE_REDIS_CLUSTER=false, REDIS_SINGLE_KEY_OPS=true
  2. Connect to AWS ElastiCache Serverless
  3. Verify no CROSSSLOT errors during cache operations
  4. Check logs for single-key-ops mode indicator

Technical Details

Files Changed:

  • packages/api/src/cache/cacheConfig.ts - Added REDIS_SINGLE_KEY_OPS configuration
  • packages/api/src/cache/redisUtils.ts - Updated batchDeleteKeys() to respect new option

Configuration:

# For AWS ElastiCache Serverless
USE_REDIS=true
USE_REDIS_CLUSTER=false
REDIS_SINGLE_KEY_OPS=true
REDIS_URI=rediss://your-elasticache-endpoint:6379

Summary by CodeRabbit

  • Chores

    • Updated build configuration to exclude development-related files and directories.
  • Improvements

    • Enhanced cache operations to support additional configuration modes for different deployment scenarios.

✏️ Tip: You can customize this high-level summary in your review settings.

…Serverless

Add REDIS_SINGLE_KEY_OPS configuration option to force single-key Redis
operations even in non-cluster mode. This is required for AWS ElastiCache
Serverless which internally shards data but doesn't support the Redis
Cluster protocol, causing CROSSSLOT errors with batch operations.

- Add REDIS_SINGLE_KEY_OPS env var (default: false) in cacheConfig.ts
- Update batchDeleteKeys() in redisUtils.ts to use single-key ops when enabled
- Add 'single-key-ops' mode logging for observability

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
@coderabbitai
Copy link

coderabbitai bot commented Jan 8, 2026

📝 Walkthrough

Walkthrough

This pull request introduces Redis operational refinement by adding a new configuration flag REDIS_SINGLE_KEY_OPS and updating deletion logic in redisUtils.ts to support three distinct modes: cluster, single-key-ops, and single-node. Build artifacts are now ignored via .gitignore updates.

Changes

Cohort / File(s) Summary
Project Configuration
\.gitignore
Added ignore rules for infrastructure directory and Playwright test files (.playwright-)
Redis Configuration
packages/api/src/cache/cacheConfig.ts
Introduced REDIS_SINGLE_KEY_OPS public configuration flag to control single-key Redis operations behavior, independent of cluster mode settings
Redis Deletion Logic
packages/api/src/cache/redisUtils.ts
Replaced simple cluster-mode boolean with nuanced mode selection using useSingleKeyOps flag; now routes deletions through cluster, single-key-ops (for sharded backends), or single-node modes with corresponding batch vs. individual-key deletion strategies

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~15 minutes

Poem

Redis modes align in graceful array, ✨
Single-key, cluster, single-node at play,
Configuration flags now guide the way,
Deletions optimized, efficient, and gay! 🎪

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and specifically describes the main change: adding Redis single-key operations support for ElastiCache Serverless, which matches the core objective of the pull request.
Description check ✅ Passed The description is comprehensive and well-structured, covering summary, problem, solution, change type, testing instructions, and technical details. It includes all critical information and follows the template structure appropriately.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between c30afb8 and ef365c8.

📒 Files selected for processing (3)
  • .gitignore
  • packages/api/src/cache/cacheConfig.ts
  • packages/api/src/cache/redisUtils.ts
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
  • GitHub Check: Run Backend unit tests
  • GitHub Check: Integration Tests that use actual Redis Cache
🔇 Additional comments (5)
.gitignore (1)

172-173: LGTM! Sensible housekeeping additions.

These ignore patterns appropriately exclude infrastructure artifacts and Playwright-generated test files.

packages/api/src/cache/redisUtils.ts (3)

34-40: Correct mode determination logic.

The useSingleKeyOps flag correctly evaluates to true when either cluster mode or single-key operations are enabled. The mode string for logging appropriately reflects the active configuration.


43-56: Branching logic correctly implements both operation modes.

The implementation properly handles:

  • Single-key mode: Deletes keys individually in parallel to avoid CROSSSLOT errors in sharded environments
  • Batch mode: Uses efficient array-based deletion for true single-node Redis

The chunking strategy balances memory usage and Redis round trips in both modes.


74-74: Enhanced observability with mode logging.

Including the operation mode in logs helps operators monitor and troubleshoot Redis deletion behavior across different configurations.

Also applies to: 78-78

packages/api/src/cache/cacheConfig.ts (1)

93-103: Implementation is correct and properly integrated.

The REDIS_SINGLE_KEY_OPS flag is well-documented and actively used in redisUtils.ts to prevent CROSSSLOT errors by switching to single-key deletion operations. The logic correctly handles interaction with USE_REDIS_CLUSTER (line 35: useSingleKeyOps = USE_REDIS_CLUSTER || REDIS_SINGLE_KEY_OPS), and the default behavior is safe.

The comprehensive JSDoc clearly explains the use case and rationale. Note that while integration tests exist for the underlying batchDeleteKeys function, there are no ElastiCache Serverless-specific tests yet—this would be a valuable addition if you plan to rely on this flag in production AWS deployments.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@busla
Copy link
Author

busla commented Jan 8, 2026

Recreating as draft PR targeting upstream

@busla busla closed this Jan 8, 2026
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.

2 participants