Avoid re-registration if member not found in UnsafeMemberAccessStrategy

[lahma]

UnsafeMemberAccessStrategy will always call Register again if member was not found. It's enough to have invalid reference in Liquid template for this endless re-registration to kick in.

[lahma]

I think this solution is not yet perfect because if you have nonexistent member in a concrete type that doesn't change its shape (be ware of dictionary, dynamic etc) the result could be cached as shared undefined accessor.

[sebastienros]

Do you mean there is a bug in your PR or before it?

[lahma]

To my understanding, it's currently a feature. The path goes to base.GetAccessor(type, name) which then finds its way to GetUnlikely and traverses interfaces etc and eventually returns null again. With fixed types/shapes this should be a definite answer and cacheable, but of course you could create a DoS by generating properties that do not exist and get cached...

[sebastienros]

Right, I think I am now caching it in the other branch I mentioned.

[sebastienros]

BTW, totally off-topic. The IncludeStatement caches the inner template file only if the value of the expression is the same. For instance {% include my_var %} is supported, and my_var contains the name of the template. The include statement instance as a single nullable ref to the parsed template, and so the template is cached if the variable has the same value during two consecutive evaluations.

Thoughts:

• one value is too small for this kind of usage, if this is a variable there is definitely more than one and then there is useless processing.
• unlimited values (dictionary) could become a DOS vector if the variable was built from outside data. But at the same time it's only cached if the file actually exists (coming from a FileProvider) so in practice there should only be a defined number of templates. In theory though these templates could be dynamic (cms?) and grow indefinitely.

What kind of structure/strategy would be appropriate here? LRU with a size limit? Weak dictionary?

[lahma]

What kind of structure/strategy would be appropriate here? LRU with a size limit? Weak dictionary?

I don't have definitive answer, like always.. Maybe for "cache miss" data it would make sense to cache a fixed set of data - for example last 10 misses that are bound to context (like Type), that could ensure that it's not unbounded. Weak dictionaries are a bit hard as they need to have something to attach to and in these cases it might not be obvious what's the GC root - I might be wrong as I really haven't thought about the problem that much / or have context.

[sebastienros]

I will ask AI, it knows everything