I implemented a cache-lookup policy in my API instance using internal cache and it's working fine.
However, I noticed this red flag in the Azure documentation:
if the cache-related operations fail to connect to the cache due to the volatility of the cache or any other reason, the API call that uses the cache related operation doesn't raise an error, and the cache operation completes successfully. In the case of a read operation, a null value is returned to the calling policy expression. Your policy code should be designed to ensure that there's a "fallback" mechanism to retrieve data not found in the cache
How should I handle that? Is the mentioned null value set in the response body so I can easily use a when condition to change the status code in the fallback path?
I wrote this code but I don't know how to simulate the "connection error", so I still don't know if it does work or not:
<policies>
<inbound>
<base />
<cache-lookup vary-by-developer="false" vary-by-developer-groups="false" downstream-caching-type="none" caching-type="internal" />
<!-- this is a mock for testing -->
<set-backend-service base-url="https://run.mocky.io/v3/redacted" />
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
<set-variable name="originalResponseBody" value="@(context.Response.Body.As<JObject>(preserveContent: true))" />
<choose>
<when condition="@(context.Variables["originalResponseBody"] == null)">
<return-response>
<set-status code="500" reason="Error" />
<set-body>{
"error": "Returning null"
}</set-body>
</return-response>
</when>
</choose>
<cache-store duration="1800" />
</outbound>
<on-error>
<base />
</on-error>
</policies>
I would like to keep my policy simple as it should be for a simple cache lookup - so I exclude to use a custom caching system like cache-lookup-value (too complex to manage in my opinion).
Anyone has faced this issue before?