feat: Integrate Redis caching for vault rates retrieval and add abstractions for cache management

[halaprix]

Description

Implemented Redis caching for the get-vault-rates-function to improve performance and reduce load on the database for the /vault/rates endpoint.

Changes

• Added @summerfi/redis-cache and @summerfi/abstractions dependencies to summerfi-api/get-vault-rates-function/package.json.
• Updated summerfi-api/get-vault-rates-function/src/index.ts to include:
  • Redis client initialization (getCacheInstance).
  • Cache key generation logic based on sorted fleet inputs (generateCacheKey).
  • Logic to check the cache before querying the database if withCache=true (or purely based on internal logic if we decide to enforce it).
  • Logic to store the database result in Redis with a 2-minute TTL.
  • Logging for cache hits and misses.

Benefits

1. Performance: Significantly reduces response time for repeated requests for the same set of fleets.
2. Scalability: Reduces the number of direct connections and queries to the database, allowing the system to handle higher concurrency.
3. Consistency: Standardizes caching behavior with other services like get-rates-function.

Testing

• Unit/Local: Verified that generateCacheKey produces deterministic keys regardless of input order.
• Integration:
  1. Call the endpoint /vault/rates with a set of fleets.
  2. Call it again with the same fleets and ?withCache=true.
  3. Verify the second call is faster and logs indicate a cache hit.
  4. Verify that changing the order of fleets in the request body still results in a cache hit (due to key sorting).

Next steps

• Monitor cache hit rates in production.
• Consider implementing caching for the /vault/historicalRates endpoint if traffic patterns warrant it.

Additional Notes

• The cache key generation sorts the input fleets by chainId and fleetAddress to ensuring that requests asking for the same fleets in different orders utilize the same cache entry.
• The implementation mirrors the pattern used in @summerfi/get-rates-function.

Summary by CodeRabbit

• New Features

  • Distributed caching for vault rate queries with deterministic cache keys and optional cache toggle

• Improvements

  • Enhanced API validation requiring fleet data (chainId and fleetAddress)
  • Increased default function timeout to 60 seconds
  • Improved error handling and logging for cache and environment conditions

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

[coderabbitai]

Walkthrough

Added a 60s timeout to generated functions, introduced Redis-backed optional caching for /vault/rates with deterministic cache keys, added input and env validation, and a noop fallback cache when Redis/config is missing.

Changes

Cohort / File(s)	Summary
Infrastructure stacks/apy.ts	Set FunctionProps timeout to 60 seconds for both VPC and non-VPC function configs.
Dependencies summerfi-api/get-vault-rates-function/package.json	Added dependencies: @summerfi/abstractions, @summerfi/redis-cache.
Handler & Cache Logic summerfi-api/get-vault-rates-function/src/index.ts	Added Redis-backed caching with deterministic generateCacheKey (sorted fleets + request param), getCacheInstance lazy init with noop fallback, withCache query handling, input and STAGE validation, conditional cache read/write, logging, and preserved DB cleanup.

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant Handler
    participant Redis as Redis Cache
    participant Service as Rates Service
    participant DB as Database

    Client->>Handler: POST /vault/rates?withCache=true
    activate Handler
    Handler->>Handler: Validate STAGE, body, fleets
    alt cache available & withCache
        Handler->>Redis: GET cacheKey
        alt hit
            Redis-->>Handler: cached response
        else miss
            Handler->>Service: init rates service
            Service->>DB: fetch fleet data
            DB-->>Service: fleet info
            Service-->>Handler: computed rates
            Handler->>Redis: SET cacheKey (TTL)
        end
    else cache disabled or without withCache
        Handler->>Service: init rates service
        Service->>DB: fetch fleet data
        DB-->>Service: fleet info
        Service-->>Handler: computed rates
    end
    Handler-->>Client: return rates response
    deactivate Handler

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

• Pay attention to: cache key determinism and sorting, Redis init/fallback logic, error/edge-case handling for missing STAGE or Redis, and interactions between cache reads/writes and service initialization.

Poem

Sixty seconds set to run the race,
Fleets sorted neat, each key in place,
Redis whispers, or stays mute,
No-op keeps the flow resolute,
Rates returned with steady grace.

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	Title accurately summarizes the main change: adding Redis caching integration for vault rates retrieval.
Description check	✅ Passed	Description covers all template sections with concrete implementation details, benefits, testing strategy, and next steps.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch kk/add-redis-to-vault-apr-lambda

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between e5b5d28 and 3c65c42.

📒 Files selected for processing (1)

• summerfi-api/get-vault-rates-function/src/index.ts (4 hunks)

⏰ 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: Build and Integration Test
• GitHub Check: Build and Unit Test

🔇 Additional comments (1)

summerfi-api/get-vault-rates-function/src/index.ts (1)

156-156: Cache write happens regardless of withCache flag, but this is intentional cache warming—fresh results are always written so subsequent requests benefit. Pattern is consistent across similar endpoints. No action needed.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between 8248991 and e5b5d28.

⛔ Files ignored due to path filters (1)

• pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml

📒 Files selected for processing (3)

• stacks/apy.ts (1 hunks)
• summerfi-api/get-vault-rates-function/package.json (1 hunks)
• summerfi-api/get-vault-rates-function/src/index.ts (4 hunks)

⏰ 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: Build and Integration Test
• GitHub Check: Build and Unit Test

🔇 Additional comments (7)

summerfi-api/get-vault-rates-function/package.json (1)

18-19: LGTM!

Dependencies align with the new caching implementation.

stacks/apy.ts (1)

38-44: LGTM!

60s timeout is reasonable for cache+DB operations.

summerfi-api/get-vault-rates-function/src/index.ts (5)

15-31: LGTM!

Deterministic key generation with proper sorting.

---

134-156: Cache always written, only conditionally read.

This warms cache for all requests but only reads when withCache=true. Intentional?

---

162-175: LGTM!

No caching for historicalRates as per PR plan.

---

187-190: LGTM!

DB cleanup in finally; Redis connection reuse across invocations is appropriate.

---

45-48: No issues found. The noop cache implementation provides both required methods (get and set) that match the DistributedCache interface exactly. The type assertion is appropriate and does not hide any missing methods.