[BUG] Auto Clone not behaving correctly for objects inside lists

[nlconor]

Describe the bug

When objects fetched from the cache with Auto Clone enabled are placed into a list and then modified, subsequent requests to the cache return the modified object.
For example: if several objects are all stored individually by ID number, when you return several of them and place them in a list - modifying the objects after they are placed in the list causes the cache object to change rather than having no effect because Auto Clone was enabled.

To Reproduce

Here's a MRE (Minimal Reproducible Example) of the issue:
https://github.com/nlconor/FusionCache-AutoCloneRepro
The /single endpoint shows Auto Clone working correctly when not using a list (as in the docs example).

The /list endpoint shows my difficulties when using cached objects inside lists.
The example works something like this:

• Tries to fetch 3 objects from the cache
• If one or more is missing then it populates the cache with 3 new objects
• For each of the "result items" (which either came from the cache or were generated this run), changes a property inside them
• Returns the changed property to the user.
  The first run works as expected but if you break on line 90 on the second run and inspect the contents of results, you will see each of the objects in the list has the User property set.

Expected behavior

When fetching objects from the cache with EnableAutoClone set, modifying the returned objects should not afffect future instances of that object - even if the objects are placed into a list.
Relating to the example - I expect that when running the /list endpoint a second time, the User property should be null on like 90 (instead of being populated by the previous run's actions).

Versions

I've encountered this issue on:

• FusionCache version 2.1.0
• .NET version 9.0.203
• OS version Mac OS 15.3.2

Thanks for all your efforts on this great library so far!

[jodydonetti]

Hi @nlconor , thanks for letting me know (and with an MRE, appreciate that!).
I'll take a look during the weekend adn will let you know.

[jodydonetti]

Hi @nlconor , thanks again for spotting this, I get to the bottom of it.

Yes, it's a bug, even though not the way you outlined it (it does not have to do with lists in particular).

Let me explain.

Explanation

The way AutoClone works is that, when getting something from the cache, FusionCache will go through a deserialization to get a copy of the value, but a deserialization from what? A serialized version of the value, that is created lazily and on the fly the first time it's requested.

Basically, if we suppose 1 SET and 2 GETs operations in a row, it currently goes like this (let's say with a Person instance):

• SET "foo" person
  • person instance is put into the cache
• GET "foo" (with AutoClone enabled)
  • need for serialized version
  • serialized version not there -> serialize on the fly
  • deserialize and return person instance
• GET "foo" (with AutoClone enabled)
  • need for serialized version
  • serialized version already there -> no need to serialize again
  • deserialize and return person instance

As you can see, the serialization is done internally only once and only if/when needed, to get the best performance and resource usage.

But what happens if you SET something in the cache, then change it, the ask for it?

It happens that the internal lazy serialization happens AFTER the live instance in the cache has been modified from outside.

Example

Basically, something like this (suppose AutoClone is enabled in the DefaultEntryOptions):

var person = new Person(...);

cache.Set("foo", person);

// HERE YOU ARE CHANGING THE LIVE INSTANCE IN THE CACHE
person.Name = "Surprise!";

// INTERNAL SERIALIZATION HAPPENS HERE
var maybePerson = cache.TryGet<Person>("foo");

Makes sense?

Solution

I just made some changes in the way AutoClone works, meaning that if AutoClone is enabled when putting something in the cache, the serialization happens right away. That's it.

In this way if you put something in the cache with AutoClone enabled, and then immediately change it after that, the internal serialized version will be already there, so any future get will not get the changes made.

Thanks again for spotting and reporting this, the fix will be included in the next v2.2.0.

Thoughts?

[nlconor]

Thank you for taking the time today to have a look at this.
Your explanation was very comprehensive & made perfect sense of what was going on here 😄.

I think that solution will sort it out - and I guess if users don't want to pay the serialization tax when storing an item (if they have Auto Clone enabled by default) then it sounds like setting EnableAutoClone to false for that action will let them store the item without serializing it immediately.

Thanks again for looking so quick 🙇‍♂️

[jodydonetti]

Hi all, v2.2.0 is out 🥳
And for the corresponding LTS-only release, there's v2.0.2.