Silent RPC failure?

[zachstronaut]

Description

We have confirmed a ServerRPC being invoked on a Client and never invoking on the Host+Server through a Log immediately before calling the ServerRPC on the client and a Log inside the ServerRPC on the server. We didn't have log levels set to Developer at the time we captured this happening, so we're unsure the cause or if the higher log level would have perhaps mentioned something. This was in Netcode 2.7.0. It seems to happen rarely when additively loading the next game level, perhaps when loading that level is slow. The ServerRPC in question lives on a NetworkObject in a scene that never gets unloaded.

But also, I noticed that in RpcMessages.cs in all Netcode versions through 2.11.2 the Deserialize method has what look like two silent failures. Are these in fact potential silent failures?

var networkObject = networkManager.SpawnManager.SpawnedObjects[metadata.NetworkObjectId];
var networkBehaviour = networkManager.SpawnManager.SpawnedObjects[metadata.NetworkObjectId].GetNetworkBehaviourAtOrderIndex(metadata.NetworkBehaviourId);
if (networkBehaviour == null)
{
    return false;
}

if (!NetworkBehaviour.__rpc_func_table[networkBehaviour.GetType()].ContainsKey(metadata.NetworkRpcMethodId))
{
    return false;
}

Environment

• OS: Windows
• Unity Version: 6000.1.17f1
• Netcode Version: see above
• Netcode Topology: Client-Server

[NoelStephensUnity]

Hey @zachstronaut!
Sorry to hear you are encountering this issue.

The script you pointed out in RpcMessage does appear to yield silent failures and should indeed log a message for troubleshooting purposes (even though both checks mean something is really wrong...either missing NetworkBehaviour or the injected ILPP code doesn't exist).

That area is within the RpcMessageHelpers class that is commonly used between universal RPCs (Rpc) and the legacy RPCS (ClientRpc and ServerRpc).

If the RPC clients are invoking works most of the time but at times it appears to not work occasionally, then it could be this one area (only if you are adjusting the NetworkBehaviour components, add or remove, such that the index is invalid):

var networkBehaviour = networkManager.SpawnManager.SpawnedObjects[metadata.NetworkObjectId].GetNetworkBehaviourAtOrderIndex(metadata.NetworkBehaviourId);
if (networkBehaviour == null)
{
    return false;
}

It is an area we should add a warning to (for sure), but the underlying issue would be (if you are modifying the components) an order of operations-oriented issue where a client hasn't invoked the script to make the adjustments to that instance before the RPC is processed.

But... if you are just loading the scene once and not making any form of modifications to the components...then you might increase the spawn timeout value (unless you have it already maxed) in the event the client requires a message to be received prior to invoking the ServerRpc (based on the description, not sure if this is the case or not) as that message could be getting dropped if it takes longer than the spawn timeout (the message that then triggers the client invoking the RPC...if such a thing exists).

If none of this sounds anywhere close to what "could" be happening, then we will need some kind of log from the client-side (if possible) and additional information regarding the order of operations/logic that occurs up to the point where the client invokes the ServerRpc in question.