NullException in NetworkObject.Deserialize when it logs a warning AND the object failed

[zachstronaut]

Netcode 2.12.0

This Warning will generate a null exception if succeeded from NonAuthorityLocalSpawn is false.

NetworkLog.LogWarning($"[{networkObject.name}][Deserialize][{nameof(NetworkBehaviour)}Synchronization][Size mismatch] Expected: {endOfSynchronizationData} Currently At: {reader.Position}!");

You can't access networkObject.name if the spawn success bool is false.

Aside:

I'm not sure what we just changed (working on it, heh) but now when we load one of our scenes I am seeing:

[Netcode] Trying to spawn a NetworkObject with a NetworkObjectId of 65 but an object with that id is already in the spawned list. This should not happen!
[Netcode] [null][Deserialize][NetworkBehaviourSynchronization][Size mismatch] Expected: 7519 Currently At: 7518!

This is how I found your null exception.

[zachstronaut]

Update: When I rolled back to 2.9.1 I still got the error about objects already in the spawned list, but there is no size mismatch warning call happening (and thus no null exception)

So I guess we've had a problem with something we're doing in this scene for quite awhile, but it didn't become fatal until that LogWarning was added sometime after 2.9.1?

[NoelStephensUnity]

Hey @zachstronaut !

Yeah... we noticed that recently too and have a fix (#4067) for this which has landed and will be in the next update.
Apologies for this, we did a sweeping pass to improve the logging and this issue crept into the mix.

Update: When I rolled back to 2.9.1 I still got the error about objects already in the spawned list, but there is no size mismatch warning call happening (and thus no null exception)

So I guess we've had a problem with something we're doing in this scene for quite awhile, but it didn't become fatal until that LogWarning was added sometime after 2.9.1?

Precisely... the warning (if NetworkObject is not null) should provide additional context but I believe there were a few places where we were silently returning without any kind of additional information. Your last issue filed regarding the RPC silently failing sort of kicked off a series of events to provide better messaging and try to make sure we were not silently failing and/or logging some obtuse message that wouldn't provide enough information to have an "idea" of what could be wrong.

So, it is very possible that you had some issues that you were not aware of...but we are trying our best to get things like this resolved globally within NGO. As an example, the newer logging system should now provide additional network logs to the server when clients run into soft synchronization errors... where originally it would just provide you with a GlobalObjectIdHash value on the client side... it now logs a warning on the client side but then logs an error on the server side (via network log) where the message sent includes the GlobalObjectIdHash that is parsed, converted to an int, and then the prefab associated with the failure is found and the name is added to the server side log (so you don't have to go hunt for the GlobalObjectIdHash value).

[NoelStephensUnity]

Will keep this open until early next week in the event you run across anything else, but the primary issue for this has been found, fixed, and will be in the next update.

Side note about v2.13.0:
There is a change to how in-scene placed NetworkObjects are being detected which, under relatively edge case scenarios, could result in a spawnd player being marked as "in-scene placed" which will cause a soft synchronization error on the client side.

This scenario requires you to be doing the following:

• Host starts in a common scene and spawns its player.
• Host loads a new scene and migrates the player to the new scene.
• Client attempts to connect and gets a soft-synchronization error.
  • Heh.. note: This will result in this issue where the NetworkObject returned is null and thus the exception you are experiencing will occur (so, you might be doing something like the above and bumping up against this).

The next update should be (very) soon and will have several fixes for v2.13.0.
I would recommend sticking with 2.12.x until the next update.

[zachstronaut]

Your last issue filed regarding the RPC silently failing sort of kicked off a series of events to provide better messaging and try to make sure we were not silently failing

Hoist by my own petard!