Summary I found a reproducible Udon networking issue where a Manual-sync UdonBehaviour begins serialization without any user-code call to RequestSerialization(). The behaviour repeatedly receives: OnPreSerialization() OnPostSerialization(success = false, byteCount = 0) while the RequestSerialization call count remains 0. The issue depends on the composition/cardinality of UdonBehaviours attached to the same GameObject. Moving the additional UdonBehaviours to separate GameObjects prevents the issue in my isolated tests. Observed Behaviour With a Manual-sync Authority UdonBehaviour and certain additional UdonBehaviours on the same GameObject: RequestSerialization calls: 0 OnPreSerialization: repeatedly called OnPostSerialization: repeatedly called SerializationResult.success: false SerializationResult.byteCount: 0 I instrumented the first unsolicited serialization attempt. At FIRST OnPreSerialization: RequestSerialization count = 0 Networking.IsClogged = false Networking.IsNetworkSettled = true Networking.IsObjectReady = true local player is owner Authority SyncMethod = Manual Therefore the first observed serialization attempt was not preceded by an instrumented RequestSerialization call and did not begin while IsClogged was true. Minimal Cardinality Reproduction Using the same Authority behaviour and repeated copies of the SAME additional ProgramAsset on the SAME GameObject produced this pattern: Additional sibling UdonBehaviours: 0 -> QUIET 1 -> QUIET 2 -> unsolicited serialization loop 3 -> QUIET 4 -> unsolicited serialization loop 5 -> QUIET 6 -> unsolicited serialization loop 7 -> QUIET The positive cases repeatedly produced: Req = 0 Pre > 0 Post > 0 success = false byteCount = 0 This was not specific to one ProgramAsset. I reproduced the same cardinality pattern with another Udon ProgramAsset: 1 -> QUIET 2 -> unsolicited serialization loop 3 -> QUIET 4 -> unsolicited serialization loop I also reproduced it using distinct sibling ProgramAssets: 1 sibling -> QUIET 2 siblings -> unsolicited serialization loop 3 siblings -> QUIET 4 siblings -> unsolicited serialization loop I am NOT claiming that all even numbers of UdonBehaviours are generally broken. This is only the reproducible pattern observed under this isolated fixture configuration. Same-GameObject Isolation I then tested the registration/layout layer. Same GameObject: Authority + two relevant siblings -> unsolicited serialization loop Split GameObjects: Authority on GO-A Sibling 1 on GO-B Sibling 2 on GO-C -> QUIET Partial split: Authority + one sibling on GO-A second sibling on GO-B -> QUIET This suggests that same-GameObject Udon registration/composition is involved. Additional Cause-Layer Tests The problem was NOT reproduced simply by creating arbitrary zero-field behaviours. Controlled variants using inert zero-field Manual / Continuous behaviours remained QUIET in my tests. Changing between zero and one synced field also did not independently reproduce the issue. Therefore I currently classify this as a multifactor same-GameObject registration/composition issue rather than a bug in one specific script, NoVariableSync alone, synced-field count alone, or Manual sync alone. Expected Behaviour For a Manual-sync UdonBehaviour: If user code never calls RequestSerialization(), the owner should not enter a continuous OnPreSerialization / OnPostSerialization failure loop. In particular, I would not expect the addition/removal or placement of sibling UdonBehaviours on the same GameObject to cause unsolicited Manual serialization. Actual Behaviour Under the affected same-GameObject composition: RequestSerialization count remains 0, but serialization begins anyway. The first observed attempt occurs while: IsClogged = false IsNetworkSettled = true IsObjectReady = true It then repeatedly calls: OnPreSerialization() OnPostSerialization(false, 0) Important distinction VRChat documentation states that failed Manual serialization may be cached and retried when networking is clogged. That could explain repeated attempts AFTER a failed serialization event. However, in this reproduction the FIRST observed serialization attempt occurs with: RequestSerialization count = 0 IsClogged = false So the unresolved issue is what creates the initial Manual serialization event. Possible Related Existing Reports https://feedback.vrchat.com/persistence/p/persistence-does-not-restore-synced-variables-in-udon-components-other-than-the https://feedback.vrchat.com/bug-reports/p/pickup-events-may-not-be-called-when-multiple-udon-components-are-attached There are existing tracked reports involving multiple Udon components on the same GameObject, including: Persistence only restoring synced variables from the first Udon component Pickup events not reliably reaching multiple Udon components Those reports may or may not share the same underlying cause. This report describes a different failure mode involving the Manual serialization lifecycle. Impact This is particularly difficult to diagnose because: gameplay code does not call RequestSerialization the affected behaviour is Manual sync the behaviour may work or fail depending on same-GameObject composition changing hierarchy/component composition can make the issue disappear the resulting failed serialization loop can continue at a high rate In a modular Udon system, adding/removing otherwise unrelated sibling UdonBehaviours can therefore change networking behaviour unexpectedly. Workaround Separating the networking Authority UdonBehaviour and the additional UdonBehaviours onto different GameObjects prevents the reproduction in my isolated test. I consider this a workaround, not an explanation of the underlying behaviour. Reproduction Evidence I have retained: isolated minimal fixtures cardinality matrices ProgramAsset identities runtime SyncMethod fingerprints first-unsolicited-event instrumentation prefab/scene hashes for tested builds repeated runtime observations I can provide a stripped minimal Unity/VRChat reproduction project if useful.
