Issue in keeping a common LookupCache policy with different cache keys

[reshmaj]

where we have a Cache Lookup policy in a shared flow, which is called twice from a proxy, each call causing a unique cache key. When the cache entry supposed to be returned by the second call expires while the first one is still in the cache, the .cachehit variable is not updated to 'false' but remains 'true' after the second call. As the succeeding policies test on .cachehit being not 'true', they are not executed and we don't obtain the value to be cached. Things go back to normal only after the first entry expires too.

@Anil Sagar @ Google

@Siddharth Barahalikar

@Dino

Could you please provide a solution??

[sidd-harth]

Can you provide policy config, trace session and request details?

[dchiesa1]

yes, show the trace please.

One thing you need to be careful of: the Trace can be misleading, specifically when showing the results of a LookupCache policy.

ref: b/111777025

So if you are drawing your conclusions about the state of the .cachehit variable from looking at the Trace, you may be mistaken.

I suggest: Insert a condition in the proxy flow that actually evaluates .cachehit, and see if it is actually true or not.

But if this UI bug is not your issue, then please do post the Trace showing the result that surprises you, and guide us on how to read the trace, what to focus on. which transaction, and which steps.

[inankanbur]

Hi,

This is originally my question, and probably my mistake not having raised it as a separate question but replying to another which I thought was relevant.

Anyway, I've prepared a simple test case, which demonstrates the behavior. Attached please find the trace of a sample run together with the the proxy and shared flow bundles (CacheTest & cachetest). Note that it requires a cache resource with name CacheTest present in the environment.

cachetest.zip

I'd be glad if you could point me what I'm doing wrong, or tell if this is a bug and, in case, possible workarounds. Thanks a lot in advance.

Regards,

-inan.

[dchiesa1]

Yes, I saw your prior question and... can you provide a sample proxy that reproduces the behavior you're describing? And a trace file?

I can try to help but I'm not clear on what you're doing. If you can clarify with a proxy and trace, it might clarify for me.

[inankanbur]

Hi,

Thanks a lot for paying attention. The zip file I attached above includes both a proxy, a shared flow, which has the cache logic, and the trace from a sample run. It just a requires a cache resource with name CacheTest.

In this example, I put different expiry times for the cached object to simulate the behaviour, but in the real solution we use the same expiry for all the cached items. It just happens that they are cached at different times.

Regards,

-inan.

[dchiesa1]

I'm looking at the Trace and I don't know what I'm looking at or looking for. I am having difficulty understanding your description. I think you want to populate and lookup cache entries for two different items. I think maybe you're using the same policy parameterized differently for that purpose. And I think you're checking .cachehit and it is not showing the value you expect.

For some reason I don't see in the trace the variable that is supposedly being assigned. I am not sure of the state of the cache entries for the three transactions. I think it would have been easier if you had separate transactions to populate the cache and lookup the cache.

But anyway if you are having problems interpreting the results from LookupCache, I suggest

1. try using a simpler assignto variable, something without dots, like

       <AssignTo>cached_value</AssignTo>
   

   instead of

       <AssignTo>flow.cache.value</AssignTo>
   

2. In the Condition, don't evaluate .cachehit. Instead, test the AssignTo variable for null.

[inankanbur]

Sorry for not being that clear. I just thought the initial explanation together with the proxy and shared flow bundles I attached would be enough.

And thanks for providing an answer anyway. Testing AssingTo variable, as you suggested, solves the problem, provided that I reset the value of the AssingTo variable in between shared flow calls or in the beginning of the shared flow regardless.

This workaround solves my problem, but I still think there's an issue with the Lookup Cache policy. I'm using the same Populate Cache and Lookup Cache policies to cache and lookup two different items. This is done by two parametrized calls to the shared flow containing those cache policies. When the item managed by the second call expires while the first item is still in the cache, the second LC execution does not set the value of .cachehit variable to 'false', or .cachehit is still 'true'. It does not reset AssignTo variable either.