If the sender's version of a class has a writeObject method, it is considered to use custom serialization, which adds two bytes at the start of the serialized data; however, the receiving side has no way to know if the sender has a writeObject method, as that does not change the repository ID. The code checks the local class to see if it has one, but that is not guaranteed to be the same as the sender's version. That could well cause deserialization to fail, if the two versions of the class differ in that regard.
To fix this, it is clear that the computation of the repository ID must take that into consideration; as far as I can tell, it does not. It is easy to write unit tests that create the failure. If the repositoryID is updated to take this into consideration, such a change will cause the use of FVD deserialization, which will indicate whether custom serialization is being used.
If the sender's version of a class has a writeObject method, it is considered to use custom serialization, which adds two bytes at the start of the serialized data; however, the receiving side has no way to know if the sender has a writeObject method, as that does not change the repository ID. The code checks the local class to see if it has one, but that is not guaranteed to be the same as the sender's version. That could well cause deserialization to fail, if the two versions of the class differ in that regard.
To fix this, it is clear that the computation of the repository ID must take that into consideration; as far as I can tell, it does not. It is easy to write unit tests that create the failure. If the repositoryID is updated to take this into consideration, such a change will cause the use of FVD deserialization, which will indicate whether custom serialization is being used.