Implement Graceful Cache Failure Handling and Logging in Initialization

[ShantanuKudva]

Issue Summary

Currently, when the cache fails, an "AssertionError: You must call init first!" error is thrown, which is not user-friendly. Instead, the system should provide a warning message indicating that the results are not cached. Additionally, during the initialization function, it should log whether the connection to Redis was successful or not.

Steps to Reproduce the Issue

1. Attempt to access cache results without initializing the cache.
2. Observe the resulting error message.

Observed Behavior

An "AssertionError: You must call init first!" is thrown, disrupting the user experience.

Expected Behavior

1. If the cache fails, a warning message should be displayed, informing the user that the results are not cached.
2. During the cache initialization, the system should log whether the connection to Redis was established successfully.

Suggested Enhancements

Graceful Failure Handling

• Modify the cache access logic to check if the cache has been initialized.
• If not initialized, return a warning message instead of throwing an error.
• Example warning message: "Cache is not initialized. Results are not cached."

Logging Connection Status

• Enhance the init function to log the status of the connection to Redis.
• Example log messages:
  • "Successfully connected to Redis."
  • "Failed to connect to Redis."

[vicchi]

Hi @ShantanuKudva ... thanks for opening this issue. Happy to look at a PR if you're open to this?

[ShantanuKudva]

Hey @vicchi, I took a sneak peek at the code and spotted where the issue is. Would you like to discuss it over Discord?
This is my ID 761135475527778314

I will try to test this out locally before doing a PR. but until then, anyone is open to fix this issue

[vicchi]

@ShantanuKudva Absolutely ... I'll ping you on Discord tomorrow (I'm in the Europe/London timezone BTW)

[ShantanuKudva]

@vicchi IST over here lmao. But yes gimme a text whenever you're free. We can discuss some potential fixes

[ShantanuKudva]

@vicchi also if i were to open a pr, are there any tests to be done before opening a pr because i see a tests folder here

[vicchi]

@ShantanuKudva Tests are always preferred where possible. Thinking about this a bit more, I think the implementation should preserve the current behaviour (throwing an exception) as users of the cache may be explicitly catching this and to have a new constructor parameter to log an error and continue (which is what I think you're saying) with the behaviour set to disabled, again to preserve existing behaviour. This is all the more important as I'd like to get this into the upcoming 0.3.0 release and if the constructor behaviour is changed then that would mean roadmapping this for the 1.0.0 release.

All of this is eminently testable. The code base on the integration branch fixes the previous test bugs by the way.

[ShantanuKudva]

Hey, so right now i have pulled the integration branch and then i have written a code that helps us test the logic. should i create a pr in the same branch or create a seperate branch?

[vicchi]

@ShantanuKudva Apologies ... the day job has taken up all of my time; the PR you've submitted is fine branch wise and I'll review it as soon as I'm able to; hopefully today or tomorrow 🤞

[ShantanuKudva]

Hey @vicchi not a problem! Please take your time and take a look at it!