Change order of operation for C# types reloading #90837
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The issue
With the following classes (granted they are used in a scene opened in editor), the reload process would trigger an error when restoring the value of
RadialPatternResolver.RadialPattern
. This happens because at the time the value is restored, we have not yet deserialized the managed callable associated with_radialPattern.Changed
. Ultimately, our reload process would consider this a fail, and the infamous.NET: Failed to unload assemblies
would show. Basically bricking the engine until we quit/restart.The fix
We now deserialize callables before reloading property states, in case a property is doing anything with the callable in its getter and/or setter.
PSA
This should not change the behaviour currently implemented (apart from fixing the actual error), but it should be noted that said behaviour might be counter-intuitive to some users. In the example used above, after the reload,
_radialPattern.Changed
would be subscribed to twice (one is from before the reload, that we now properly restore, the other from during the reload, when the property's state is restored). We can see this is the currently implemented behaviour by connecting the signal with the deferred flag (this basically bypasses the original timing issue). I included this in the provided MRP.This is probably not ideal, but we probably don't want to widely change the behaviour here. Users can implement the
ISerializationListener
if they need finer control.Minimal reproduction