RPC called on despawned pooled network object

[CRG-Viktor]

Test case:

1. Run an instance as host with a server tick rate of 30
2. Spawn a pooled network object containing an RPC method with the [ObserversRpc(RunLocally = true)] attribute
3. Call the RPC method
4. One frame after the RPC method is called, call a method on the spawned pooled object from LateUpdate that calls Despawn(DespawnType.Pool); (The timing here could be dependent on the tick rate of the server, since the issue doesn't appear if the despawn is delayed for a longer time)

Wanted Result: The RPC method shouldn't be called again on the despawned pooled network object.

Actual Result: The RPC method is call again on the now despawned pooled network object.

[FirstGearGames]

I will investigate but this may not be a bug. Objects don't actually despawn as host until the clientHost gets the despawn packet. What could be happening is you're sending the rpc and then calling despawn, and they would be arriving in the proper order.

However, if the object is disabling first and then receiving the rpc it could be a bug.

[FirstGearGames]

Confirmed to not be a bug. The object does not 'despawn' until the client receives the despawn message when acting as host. This is in place to prevent the negatives of your scenario.

EG: let's say separate client and server. Server -> RPC. Server -> Despawn. Client <- RPC. Client <- Despawn.

This is normal expected behavior. ClientHost does the same.

If the object were to 'despawn' immediately results would look like this.... Server -> RPC. Server -> Despawn. Client <- RPC (object not found!). Client <- Despawn (object not found!).