nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Connected Content Order of Operations-- :save :retry :cache_max_age?

abenton

Hi all, is there a specific order I need to have :save, :retry, and :cache_max_age in on an API call? Example attached... we're seeing some interesting behavior where cache doesn't seem to be working as intended so want to confirm we have this set up correctly. I can't find any documentation on this in Braze or elsewhere. Thanks!

Find more posts tagged with

Connected Content

Comments

Arso

@abenton what's the intended behavior and what do you see? It might help troubleshoot this. Does it keep making API calls with the same parameters within the 20 minutes you've set for the cache age?

I don't think that the order of operations plays a role here and I couldn't find any documentation on it either, but to be safe, I'd set the cache age first, then retry and ultimately save.

There's something in the documentation about Braze using a volatile cache system and the data being removed from cache earlier than expected.

Connected Content cache time can be configured to be longer with :cache_max_age, as shown in the following example. The minimum cache time is 5 minutes and the maximum cache time is 4 hours. Connected Content data is cached in-memory using a volatile cache system, such as memcached. As a result, regardless of the specified cache time, Connected Content data may be evicted from Braze’s in-memory cache earlier than specified. This means the cache durations are suggestions and may not actually represent the duration that the data is guaranteed to be cached by Braze and you may see more Connected Content requests than you may expect with a given cache duration.

https://www.braze.com/docs/user_guide/personalization_and_dynamic_content/connected_content/local_connected_content_variables/#configurable-caching

AllanHeoFNM

Hi Abby,

From my understanding, the order of the parameters shouldn't matter in the Connected Content call. Connected Content calls are tricky because it's tough to diagnose exactly where the root cause is.

It's also possible that the internal server that you're pinging with your Connected Content could have some limitations which may be causing the issue. It's helpful to loop in any engineering resources (if possible) who helped stand up that internal endpoint.

Lastly, the Braze support team might be able to look into further logs that you may not have access to. I would definitely give them a try.

Best of luck!

Allan

DavidO

The volatile cache note in the docs is a great find @Arso,.Thanks for highlighting this.

bob

Depending on the nature of the call itself, I've seen that caching just not work at all sometimes. Not just with a quicker than expected expiry. In those cases I ended-up manually caching a response in a content block for later re-use.