CASE: Solving a cache issue

First, it is important to understand what a cache issue is, and how the three level dependencies limitations work. You can check the documentation about it on the Developer Documentation.

If in one of your templates you see this warning in your debug panel, it means that you have reached the limit of dependencies in your template. And starting from this point, new dependencies could have potential differences in the cache (impacting how the data is calculated)

Consider the following scenario:

Here you have a “chain of results” across different templates, exceeding the 3 levels in your chain. Some calculation is performed in Reconciliation 1 and stored in a result. This result is picked up in Reconciliation 2, you perform some extra calculations and store it in a new result. You continue in that same logic until you reach Reconciliation 4.

How do you “solve” this issue?
Considering this previous case, the values that you display in the last reconciliation could be wrong. What you need to do is transform Reconciliation 3 into your second item in the chain, so that it’s no longer the third level. This implies that it should have a direct link with all the required reconciliations in the chain of dependencies.
Reconciliation 3 already has a “direct link” with Reconciliation 2 because it calls upon its results. But it doesn’t have a direct link with Reconciliation 1, since it’s using those results through Reconciliation 2.

Then what can you do?
Re-think the data flow between your templates. Restructure your template in a way that decreases the amount of levels in the chain. Though this may not always be possible, this is the preferred solution as it will ensure the smoothest experience performance-wise.

There is however also a liquid solution in case you’re not able to reduce the levels in your dependency chain by restructuring the template. You can simply add calls upon the results of Reconciliation 1 in Reconciliation 3. Even if you are not using these results, and you keep using the original flow, this will force Silverfin to render Reconciliation 1 right before Reconciliation 3. For example:

{% assign results_reconciliation_1 = period.reconciliations.handle_1.results %}

Now, simply by adding this line of code, you will ensure that there are no longer potential differences in Reconciliation 4 (and you won’t see the original warning in the debug panel anymore).
Also by adding this line of code, there is no need to modify any of your existing logic in the code. Your original logic across templates remains exactly the same.

So in this case, the “first level” in the chain of dependencies are results from a Reconciliation, but what would happen if, for example, the first level are accounts coming from the Trial Balance, or the company drop ? The idea is the same; instead of creating a “link” to results of the other reconciliation, you create one to the accounts drop or company drop. For example:

{% assign accounts = period.accounts %}

In conclusion, you should always keep data flow and dependencies in mind when designing templates. It’s better to avoid having to fix cache issues in the first place, as the fix can negatively impact template performance.