[quantum-shubham]

TITLE:
fix: NetworkList changes pending during client synchronization are applied twice

BODY:

Purpose of this PR

Fixes #4179

If a client is synchronized while a NetworkList<T> still has unsent changes, the synchronization snapshot already contains those changes. On the next tick the same events are sent to the new observer again. Add, Insert, Remove, RemoveAt and Set are not idempotent, so the late-joining client ends up with duplicate entries, and later index-based events land on the wrong elements. #3081 fixed this for NetworkVariable<T> through WriteFieldSynchronization, but NetworkList<T> never overrode it.

NetworkList<T> now overrides WriteFieldSynchronization, mirroring NetworkVariable<T>. While local changes are pending, it writes the list as it was before the first of them. The pending events then bring the client up to date exactly once with the next delta.

The copy is taken just before the first local change after a delta is sent, and the flag is cleared in ResetDirty. It is not refreshed in ResetDirty, because there it could go stale on instances where ResetDirty doesn't run, such as a non-writer that later becomes owner. Paths without locally pending events behave exactly as before: server forwarding of owner-write deltas, NetworkShow (already flushed by ForceSendIfDirtyOnNetworkShow), and spawn.

Tradeoff: each NetworkList<T> keeps one extra native buffer, and the writer does one copy per dirty period.

Jira ticket

N/A (GitHub issue #4179)

Changelog

• Fixed: Issue where a client synchronized while a NetworkList<T> still had unsent changes applied those changes twice, resulting in duplicate entries and index-based events landing on the wrong elements on that client.

Documentation

• No documentation changes or additions were necessary.

Testing & QA (How your changes can be verified during release Playtest)

Functional Testing

Manual testing :

• Manual testing done

Automated tests:

• Covered by existing automated tests
• Covered by new automated tests

New NetworkListTests.LateJoinWithPendingChanges (Host / DAHost / Server). It holds deltas back with MinSecondsBetweenUpdates, applies Add/Insert/RemoveAt/Set/Remove, late-joins a client, checks the changes are still pending, releases them, and verifies every client matches.

• Without the fix, the new test fails in all three modes (Expected: 5, Have: 6 on the late-joined client).
• With the fix, PlayMode on Unity 6000.0.72f1 (testproject) passed 1044/1044 across the related suites: NetworkVariable*, NetworkList*, NetworkShowHide, NetworkObjectSynchronization, NetworkObjectOwnership, OwnerModified and the permission/hidden variable tests.

Does the change require QA team to:

• Review automated tests?
• Execute manual tests?
• Provide feedback about the PR?

Up-port

The same code exists on develop-3.x.x. I can open the up-port PR once this one is reviewed.

Backports

Not needed.

[EmandM]

Thank you for your submission! We're quite busy preparing for an upcoming release so we'll have time to review this at the end of the month.

[EmandM]

In a stroke of luck I've had time to review this PR!

This looks like a great fix. I like how you've matched the pattern we were already using in NetworkVariable. The working test is also very appreciated. Gives us a lot more confidence in the correctness of your approach.

Unfortunately, we can't run our tooling on forked repos. For next steps I will open a PR on an internally created branch and cherry-pick your fix over. I will then close this PR. We'll run all our testing and internal review process, and then hopefully we can get this fix into our next release.

Thank you for your contribution!

[EmandM]

#4215 is the internal branch for this PR. This PR will continue there

[quantum-shubham]

Thanks for the update. I will continue contributions while maintaining the quality. Best Regards Shubham Kumar

…

On Sat, 24 Oct, 2026, 02:33 Emma, ***@***.***> wrote: ***@***.**** approved this pull request. In a stroke of luck I've had time to review this PR! This looks like a great fix. I like how you've matched the pattern we were already using in NetworkVariable. The working test is also very appreciated. Gives us a lot more confidence in the correctness of your approach. Unfortunately, we can't run our tooling on forked repos. For next steps I will open a PR on an internally created branch and cherry-pick your fix over. I will then close this PR. We'll run all our testing and internal review process, and then hopefully we can get this fix into our next release. Thank you for your contribution! — Reply to this email directly, view it on GitHub <#4200?email_source=notifications&email_token=BC6LZERUTUNVGS6ADTJ52X35VPBRLA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTKNRTGQ2DCNRQGAY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-5634416001>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BC6LZEV3ZF4EB45XV4CCVEL5VPBRLAVCNFSNUABFKJSXA33TNF2G64TZHMYTCNRTHA2TEMBTHNEXG43VMU5TKOJTGY4DONBUGY3KC5QC> . You are receiving this because you authored the thread.Message ID: <Unity-Technologies/com.unity.netcode. ***@***.***>