Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

NetworkList changes made since the last tick are applied twice on a newly synchronized client

Aberta
  • Algo errado?
#4,179 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 2 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
55/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
csharp, unity
Domínio
networking

Direção de pesquisa

Start at NetworkList synchronization and compare its behavior with NetworkVariable's WriteFieldSynchronization fix from #3081. Trace NetworkBehaviour.WriteNetworkVariableData, SynchronizeNetworkObjects, and NetworkBehaviourUpdater.ProcessDirtyObjectServer, then reproduce the late-join case; done means the new client's list matches the server without duplicate events.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

stat:awaiting-triage stat:reply-needed type:bug
Description

When a client is synchronized while a NetworkList<T> on an already spawned object still has unsent changes, that client applies those changes twice: once from the synchronization snapshot and again from the next tick's delta. Add, Insert, Remove, RemoveAt and Clear aren't idempotent, so the client's list ends up with duplicate entries, and every later index-based event lands on the wrong element on that client. Clients that were already connected are unaffected.

#3081 fixed this for NetworkVariable<T>: WriteFieldSynchronization serializes the previous value while changes are pending. NetworkList<T> doesn't override it, so NetworkBehaviour.WriteNetworkVariableData falls back to WriteField and writes the current contents while m_DirtyEvents is still populated. By the next tick the new client is an observer, so NetworkBehaviourUpdater.ProcessDirtyObjectServer sends it the same events.

The frame ordering makes this deterministic, not a race. Connection requests and approvals are handled in EarlyUpdate (HandleConnectionApproval → SynchronizeNetworkObjects, which adds the observer and serializes the snapshot immediately), while deltas go out on the tick in PreUpdate. Any structural change made in Update or LateUpdate of the previous frame is therefore always still pending when the snapshot is taken. That includes changes made while completing an async ConnectionApprovalCallback (response.Pending = false in the same frame), which is how we hit it.

NGO already flushes pending deltas before NetworkShow (NetworkBehaviourUpdater.ForceSendIfDirtyOnNetworkShow) and before ownership changes (#3081), but not before synchronizing a connecting client.

Reproduce Steps
  1. Add this component to an in-scene placed NetworkObject (scene management on, connection approval off):
using Unity.Netcode;
using UnityEngine;

public class NetworkListLateJoinRepro : NetworkBehaviour
{
    private NetworkList<int> values = new();

    private void Update()
    {
        // One entry per frame; whatever was added after the last tick is still pending
        // when the next connection request is handled in EarlyUpdate.
        if (IsServer && IsSpawned) values.Add(Time.frameCount);
    }

    public override void OnNetworkSpawn()
    {
        if (IsServer) return;

        int newestInSnapshot = values.Count > 0 ? values[values.Count - 1] : -1;
        values.OnListChanged += change =>
        {
            if (change.Type == NetworkListEvent<int>.EventType.Add && change.Value <= newestInSnapshot)
                Debug.LogError($"{change.Value} was already in the synchronization snapshot and was added again.");
        };
    }
}
  1. Start a server (dedicated or host).
  2. Connect a client.
  3. See the error on the client: the entries the server added after its last tick, before it handled the connection request, arrive in the snapshot and again as Add events. The client's values.Count ends up higher than the server's.
Actual Outcome

The newly connected client applies the pending events on top of a snapshot that already contains them. It gets duplicate entries, and later Value/RemoveAt/Insert events hit the wrong indices on that client only. In our game, every entry the server added while completing the first player's approval (bots joining the match) appeared twice in that player's stats, player info and team lists, which broke the scoreboard.

Expected Outcome

The client's list matches the server's, the way NetworkVariable<T> behaves since #3081.

Screenshots

n/a

Environment
  • OS: Windows 11
  • Unity Version: 6000.6.0f1
  • Netcode Version: 2.13.3. The same code is in the 3.0.0 package and on develop-2.0.0 and develop-3.x.x as of 2026-10-03.
  • Netcode Commit hash: n/a (installed from the package registry)
  • Netcode Topology: Client-Server (dedicated server), scene management enabled
Additional Context

Possible fixes (either should work):

  • Override WriteFieldSynchronization in NetworkList<T> to write the list as of the last sent delta, e.g. a copy refreshed in ResetDirty, mirroring NetworkVariable<T>'s previous value.
  • Flush pending deltas in HandleConnectionApproval before the client becomes an observer, as ForceSendIfDirtyOnNetworkShow does for NetworkShow.

Workaround we're shipping, confirmed to fix it. It has to be compiled into Unity.Netcode.Runtime through an .asmref because these APIs are internal:

// INetworkHooks, registered with networkManager.MessageManager.Hook(...) in OnServerStarted.
// ConnectionApprovedMessage is sent after AddClient but before SynchronizeNetworkObjects makes
// the client an observer, so the flush only reaches clients that already have the old state.
public void OnBeforeSendMessage<T>(ulong clientId, ref T message, NetworkDelivery delivery) where T : INetworkMessage
{
    if (typeof(T) != typeof(ConnectionApprovedMessage)) return;
    networkManager.BehaviourUpdater.NetworkBehaviourUpdate();
}

This only works with scene management enabled. With it off, the snapshot travels inside ConnectionApprovedMessage itself, which is serialized before the hook runs.

Related: #3999 (same duplicate for changes made in OnNetworkSpawn), #2454 (NetworkShow), #2462, #1590.

Linguagem predominante
C#
Estrelas
2.3k
Forks
464
Merge médio
2d 18h
PRs com merge (30d)
15

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de Unity-Technologies/com.unity.netcode.gameobjects

Todas as issues de Unity-Technologies/com.unity.netcode.gameobjects

Issues semelhantes

Mais issues de C#

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.