Bug Incorrect IResourceLocation.ResourceType for ScriptableObjects after Unity version update

We've encountered very weird issue after switching from Unity 2020.3.14f1 to 2020.3.26f1. Content built in the new version contains incorrect ResourceType as detected by calling
Addressables.LoadResourceLocationsAsync passing a label and then printing out the ResourceType values in the text file.

I came to this conclusion using the following code and then comparing the result text files in different versions of Unity:

Code (CSharp):

1. File.WriteAllLines(Path.Combine("Temp", "locations.txt"), _locations.Select(l => $"{l.InternalId}|{l.PrimaryKey}|{l.ProviderId}|{l.ResourceType}|{l.Data}"));

(where _locations contains the result of LoadResourceLocationsAsync with only distinct values by InternalId)

Here's the output for the same asset in different versions:

Code (csharp):

1.  
2. Assets/Preloaded/Config/Items/Head_Agi_0.asset|Preloaded/Config/Items/Head_Agi_0.asset|Lib.Unity.Assets.ResourceProviders.SyncBundledAssetProvider|Mechanic.Battle.Impl.Shared.Configs.EquipmentConfig.HeadItemConfig|
3.  
4. Assets/Preloaded/Config/Items/Head_Agi_0.asset|Preloaded/Config/Items/Head_Agi_0.asset|Lib.Unity.Assets.ResourceProviders.SyncBundledAssetProvider|Sirenix.Serialization.SerializationData|
5.  

Notice the weird value of Sirenix.Serialization.SerializationData. Digging further, I've found that this is the type that Odin serializer uses for it's SerializedScriptableObject class. HeadItemConfig inherits from this type, which itself, is a sub-type of ScriptableObject. Here's a code for that class for reference:

Code (CSharp):

1. /// <summary>
2.   /// A Unity ScriptableObject which is serialized by the Sirenix serialization system.
3.   /// </summary>
4.   [ShowOdinSerializedPropertiesInInspector]
5.   public abstract class SerializedScriptableObject : ScriptableObject, ISerializationCallbackReceiver
6.   {
7.     [SerializeField]
8.     [HideInInspector]
9.     private SerializationData serializationData;
10.  
11.     void ISerializationCallbackReceiver.OnAfterDeserialize()
12.     {
13.       UnitySerializationUtility.DeserializeUnityObject((Object) this, ref this.serializationData);
14.       this.OnAfterDeserialize();
15.     }
16.  
17.     void ISerializationCallbackReceiver.OnBeforeSerialize()
18.     {
19.       this.OnBeforeSerialize();
20.       UnitySerializationUtility.SerializeUnityObject((Object) this, ref this.serializationData);
21.     }
22.  
23.     /// <summary>Invoked after deserialization has taken place.</summary>
24.     protected virtual void OnAfterDeserialize()
25.     {
26.     }
27.  
28.     /// <summary>Invoked before serialization has taken place.</summary>
29.     protected virtual void OnBeforeSerialize()
30.     {
31.     }
32.  
33.     [HideInTables]
34.     [OnInspectorGUI]
35.     [PropertyOrder(-2.147484E+09f)]
36.     private void InternalOnInspectorGUI() => EditorOnlyModeConfigUtility.InternalOnInspectorGUI((Object) this);
37.   }

As you can see, all it does is modifying the contents SerializationData property during Serialize/Deserialize to accommodate Odin's serialization features. The question is why Addressables writes this value into the ResourceType instead of an actual type of a given ScriptableObject and why it only happens in certain patch versions of Unity?

I've tried contacting developers of Odin, but it seems there's nothing they can do as Odin does nothing special here and just uses the UnityEngine.ISerializationCallbackReceiver that Unity provides. Something somewhere in the Addressables Editor code gets confused during build and writes the incorrect value.

This was tested on Addressables versions 1.19.4 and 1.19.17 (no change).

 

Reported case 1395985. After doing a minimal repro I saw that actually there are duplicate locations being created for the ScriptableObject in case of SerializedScriptableObject. One is correct, while other one is not.