Yesterday, I was tasked with upgrading Redis from version 4 to version 6 due to Azure's retirement of the older version. The first step was to check for any potential risks involved in the upgrade process. I changed the connection string to test the application's functionality and was surprised to find that the application was working perfectly fine in the local environment.

Although I had some doubts about the validity of my approach, the fact that the application was able to retrieve data from the cache even with a random connection string made me believe that the system had a caching mechanism in place to retrieve data from the server if the cache source was unavailable. However, I was asked to test the application's functionality in a lower environment, which led me to discover that a bad connection string should have thrown an error and it threw an error as expected in the lower environment.

Initially, I thought that the system had a caching mechanism in place to retrieve data from the server when no cache was available. But as it turns out, this assumption was incorrect when I checked the code in a development environment. I was wrong in assuming that the application was retrieving data from the server when no cache was available, as it was actually retrieving data from the default cache provider instead of Redis. All this are in local.

Further exploration of the lower environment revealed that the application was throwing a "host not found" error on changing the connection string to a random one. It was then that I realized that my local approach was flawed and needed further investigation. I discovered that although the logic was designed to retrieve data from Redis, the configuration was set to take data from the default cache here the default cache is nothing but getting the data from the server itself. The web.config file did not have any transformation logic to change the connection string or the cache store when Redis was not working as expected.

To resolve this issue, I began investigating the Redis local setup and discovered that a step to enable the cache had been missed. So the implementation was kind of lot to have with the fallback mechanism. Once I made the necessary changes to enable Redis, I began receiving the same error in the lower environment.