Bug: Dynamic Variables don't invalidate properly when destroyed

[JackTheFoxOtter]

Describe the bug?

Not quite sure if the description is accurate, but the issue definitely exists and is easily reproducable.

It seems like when a slot with Dynamic Variables on it gets destroyed and immediately re-created (from a template), non-local clients never see the variables updating and incorrectly sync the last value they saw back into the dynamic variable space.

Relevant issues

N/A

To Reproduce

The Slots "Target Space" and "Template Space" each have a DynamicVariableSpace component. The Slot "State" has a single DynamicValueVariable, it's set to 0 in the template.

The steps are

• Replace the previous State / duplicate the initial one by triggering the impulse
• Inspect the duplicated "State" Slot under "Target Space".
• Change the value to something else, for example 42
• Trigger the impulse again
• Inspect the duplicated "State" slot under "Target Space" again.

If the local user is the only user in the world:

• The resulting value will be 0, which is correct, as it has been copied over from the template.

If other users are present in the world:

• The resulting value will be 42, which is incorrect.

Expected behavior

The resulting value should be 0 regardless of if other users are present in the world, since it's getting copied over from a template and is never intentionally changed afterwards.

Log Files

No response

Screenshots

No response

How often does it happen?

Always

Does the bug persist after restarting Neos?

Yes

Neos Version Number

2022.1.28.1310

What Platforms does this occur on?

Windows

Link to Reproduction Item/World

No response

Did this work before?

I Don't Know

If it worked before, on which build?

No response

Additional context

I think what's happening is that the other user never sees the value / dynamic variable space change / update because the resulting hierachy is identical. For whatever reason though, the other user then re-syncs the last value they have seen into the dynamic variable space. I think that only the user that actually changed the space should sync what they see as the value, as they are the one that changed it / have the correct value.

In my test case, the local user was the host. I'm not sure if this makes a difference.

Reporters

No response

[gentlecolts]

Interesting bug, I don't think the hierarchy is identical as I'd assume the slots would have different refs, which is what would actually matter. If I had to guess, because this is all happening on the same update cycle, it's possible that only some users may see the variable "leave" the space before it's re-created, as if, for example, to them the old slot was duplicated (now two references to the variable in the space) before the old one was deleted (back to one reference, was never a need to garbage collect/unreference)