[DA] Ownership requests intermittently fail, OnOwnershipRequested callback not invoked on owner

[KadaXuanwu]

Description

Ownership requests intermittently fail in Distributed Authority topology after restarting matches multiple times. When the bug occurs, RequestOwnership() returns RequestSent, but the callback OnOwnershipRequested is never invoked on the owner's side, and the requester receives CannotRequest in OnOwnershipRequestResponsed. This affects dynamically spawned NetworkObjects (bomb, gems) used for pickup mechanics. However, the session owner is always able to request ownership, this bug only occurs for other clients.

When the game ends, the players are put back to the lobby scene and all NetworkObjects are destroyed by having each client loop through all their owned NetworkObjects and calling networkObject.Despawn(false);. Note that I never call SetOwnershipStatus() anywhere. More code details below.

The issue is not consistently reproducible and typically manifests after completing several matches with different game modes. I'm not sure if this bug is a NGO issue or if it's specific to my project.

Reproduce Steps

1. Set up a Distributed Authority session with multiple clients
2. Spawn a NetworkObject (e.g., bomb) with Ownership set to Distributable and RequestRequired
3. Play through multiple matches, transitioning players between lobby and game scenes
4. Despawn non-persistent owned objects when returning to lobby
5. Start a new match and attempt to request ownership of a freshly spawned object
6. At some point (non-deterministic), ownership requests stop working

Actual Outcome

• RequestOwnership() returns OwnershipRequestStatus.RequestSent
• The owner never receives the OnOwnershipRequested callback
• The requester receives OwnershipRequestResponseStatus.CannotRequest in OnOwnershipRequestResponsed
• The ownership status flags on the NetworkObject appear correct on both sides
• Once bugged, repeated requests do not resolve the issue
• Some objects in the same session work correctly while others don't

Expected Outcome

• Owner should receive OnOwnershipRequested callback
• If approved, requester should receive OwnershipRequestResponseStatus.Approved
• Ownership transfer should complete successfully

Screenshots

A screenshot of the NetworkObject of the bomb (object to pick up) on the Client trying to pick up and SessionOwner. Please note that they are taken in different matches, therefore the difference in ID.

That's how I configured the NetworkObject in the editor.

Environment

• OS: Windows 11
• Unity Version: [Please specify]
• Netcode Version: 2.7.0 (also reproduced on 2.5.1)
• Netcode Commit: [If known]
• Netcode Topology: Distributed Authority

Additional Context

Ownership request code (on player):

if (bombNetworkObject.IsOwner)
{
    RequestBombPickUp(bombNetworkObject);
}
else
{
    RequestBombOwnership(bombNetworkObject); // Client tries requesting ownership
}

private void RequestBombOwnership(NetworkObject targetObject)
{
    if (!targetObject.IsRequestInProgress)
    {
        targetObject.RequestOwnership(); // returns OwnershipRequestStatus.RequestSent
    }
}

Ownership callbacks (on bomb):

private bool EventOwnershipRequested(ulong clientRequesting)
// Owner doesn't receive it when it bugs, otherwise does
{
    // return false in some specific scenarios
    return true;
}

private void EventOwnershipRequestResponse(NetworkObject.OwnershipRequestResponseStatus ownershipRequestResponse)
// CannotRequest when it bugs, otherwise Approved
{
    if (ownershipRequestResponse == NetworkObject.OwnershipRequestResponseStatus.Approved)
    {
        // Pick up
    }
}

Scene transition cleanup:

public static void DespawnNonPersistentOwnedNetworkObjects()
{
    if (NetworkManager.Singleton == null || !NetworkManager.Singleton.IsClient)
    {
        Debug.LogWarning("NetworkManager is not initialized or this is not a client instance.");
        return;
    }

    ulong localClientId = NetworkManager.Singleton.LocalClientId;
    NetworkObject[] ownedObjects = NetworkManager.Singleton.SpawnManager.GetClientOwnedObjects(localClientId);

    foreach (NetworkObject networkObject in ownedObjects)
    {
        if (networkObject != null && networkObject.IsSpawned)
        {
            if (networkObject.gameObject.scene.name != "DontDestroyOnLoad")
            {
                networkObject.Despawn(false);
            }
        }
    }
}

Observations:

• Using the latest NGO 2.7.0 package
• The bug appears related to match restarts and scene transitions
• Multiple object types are affected (bomb, gems)
• NetworkObject settings: Ownership = Distributable, with RequestRequired enabled
• Possibly related to internal state not being cleaned up correctly during session/scene transitions

[EmandM]

Thanks for reporting this. To narrow down the issue further, is there any chance you can share any of the LobbyIds where this has occurred?

There is a chance we're not resetting the ownership flags properly between object spawns. To see if that's the problem, can you try adding the following line to the OnNetworkSpawn of an object that's having issues?

SetOwnershipStatus(NetworkObject.OwnershipStatus.Distributable | NetworkObject.OwnershipStatus.RequestRequired, true);

If that is the problem, then this will manually reset the flags when the object is respawned and the issue should resolve.

[KadaXuanwu]

Hi, as an example, I've had the issue in the following two lobbies (ID):
ZmXSeR3AGxbqT4oEtG6f5T
zQy3ZjCGKP7996JmYYRNJY

The two screenshots I shared are NetworkObjcets at runtime (client view and session owner view) at the time the bug occurred. It looks like the ownership flags are set correctly even when the issue is here.

However, adding this line actually resolved the issue:
SetOwnershipStatus(NetworkObject.OwnershipStatus.Distributable | NetworkObject.OwnershipStatus.RequestRequired, true);

Thanks for the hint, I'll use that for now, but I still believe there is something wrong when spawning these network objects since I never change the ownership status anywhere and instantiate & spawn new objects every round.

[EmandM]

I'm glad that fixes it!

This is an issue on our side that we'll fix. The network object should be cleaned up properly when the next session starts.

What's happening is that when a client accepts a request, first they set a flag on the object to mark the object as "already requested by someone". That flag will be cleared when the client who made the request receives the request approval. The flag helps guard against flip-flopping ownership. Essentially, it protects the object until the new owner knows that they were approved as the new owner.

If the object is despawned or the session ends before that flag is cleared, then the object will still have the "already requested" flag set. However none of the clients know that it's an invalid or outdated flag. The owner can unset the flag but they don't know they need to. That's why everyone starts seeing the "CannotRequest" status.

The true parameter in SetOwnershipStatus(NetworkObject.OwnershipStatus.Distributable | NetworkObject.OwnershipStatus.RequestRequired, true) will clear and reset those extra flags. That'll ensure that any new spawn doesn't have any leftover state persisted.

We'll import this as a bug on our side and ensure that those extra flags are cleared in-between spawns!