Handle Redis write failures gracefully in daily tip caching flow #364

Affected file

tipController.js

Description

The daily tip controller uses Redis as a cache layer for the “tip of the day” response. The read path appears to tolerate Redis lookup failures, but the cache write path does not consistently guard against Redis write errors.

In the current flow, after the controller determines the daily tip (either from cache-miss logic or a fallback/default path), it attempts to write the result back to Redis. If the Redis write operation fails, the entire endpoint can fail even though the application already has a valid tip response ready to return.

This makes the API unnecessarily dependent on Redis write availability for a request that could otherwise still succeed using database or fallback data.

Why this is a problem

A cache write failure should not usually break a read endpoint if the actual response data has already been computed successfully.

Impact

• The endpoint becomes less resilient to Redis instability or temporary cache outages
• Users may receive 500 errors even though the application could have returned a valid daily tip without caching it
• Redis becomes a hard dependency for successful response delivery in a path that should primarily be read-oriented
• Cache infrastructure failures can affect application correctness instead of just performance

Current behavior

The controller uses Redis caching in the daily tip flow, but the cache write step is not fully isolated from the main response path. If the write fails, the request may fail instead of returning the already-resolved tip data.

Expected behavior

If Redis cache writes fail:

• the controller should still return the daily tip response successfully
• the cache write failure should be logged or handled internally
• the endpoint should degrade gracefully instead of failing the request

Suggested fix

Wrap Redis write operations in a dedicated try/catch block or otherwise isolate them from the main response path.

Suggested approach

1. Resolve the daily tip from cache / database / fallback logic

2. Prepare the response payload

3. Attempt to cache it in Redis inside a guarded block

4. If the Redis write fails:

   • log the error
   • continue returning the resolved response normally

Avoid letting cache write failures turn the entire endpoint into a 500 unless cache consistency is truly critical.

Benefits of this fix

• Makes the daily tip endpoint resilient to Redis write failures
• Prevents avoidable 500 responses when valid tip data is already available
• Keeps Redis as a performance optimization instead of a hard dependency
• Improves graceful degradation during cache outages or transient Redis issues

Suggested fix summary

Update the daily tip caching flow so that Redis write failures do not break the endpoint after the tip response has already been resolved.

At a minimum, the fix should:

• isolate Redis write operations from the main response path
• log cache write failures instead of surfacing them as endpoint failures
• still return the resolved daily tip response when caching fails