Hi. I’m trying to find a replication error in Iris that is happening in our live Game. It’s very hard to reproduce unfortunately.
On certain packets the Iris FReplicationReader overflows entering an object batch and tears down the connection. On a dev build with UE_NET_USE_READER_WRITER_SENTINEL enabled we get:
LogIris: Error: Overflow: N Error: Invalid value Bit stream bits left: 0 position: <N>
ReadAndVerifySentinelBits ReadObject failed OverFlow 1 Got 0x0 != 0x173 [NetBitStreamUtil.cpp:915]
Ensure condition failed: !Context.HasErrorOrOverflow() [ReplicationReader.cpp]
LogNet: Error: Received corrupted packet data. Iris cannot recover from this.
The ReadObject sentinel fails with bits-left:0 right at a batch boundary — i.e. the read loop reaches end-of-bitstream and calls ReadObjectBatch on an exhausted stream.
Representative sentinel journal (client):
SubObject EffectTrackerComponentComp tied to RootObject BP_SomeRedactedActorNameA_C
… OwnerEffectContainer (2146 bits)
SubObject AbilitySystem tied to BP_SomeRedactedActorNameB_C
Attachments → GameplayCueTag → GameplayCueParameters → GameplayEffectContext (×2, 487/409 bits)
RootObject SomeRedactedActorNameC_C
…ReplicatedMovement → State → CharacterMovementComponent_Functions → ReadObjectBatch → OVERFLOW (bits left 0)
(All earlier batches pass their ReadObject sentinels; only the final one fails at bits-left:0. We can share full journals for multiple occurrences.)
Context from your history. We found CL 42772678 (4e75dfe74b6c, “Gracefully handle reaching the end of the bitstream”, cvar net.Iris.ReplicationReader.GracefullyHandleReachingEndOfBitstream, default-on in 5.6) which hardens exactly this loop; we note 5.7 flips that default to off, and we could not find a corresponding writer-/serializer-side change.
Our question. Have you encountered this exact pattern under Iris (5.5/5.6) — ReadObjectBatch overflow / “corrupted packet, cannot recover” — and specifically in connection with (a) customFGameplayEffectContextsubclasses viaDerivedFromCustom, and/or (b) replicated object references to net-culled/non-relevant actors inside FastArrays or custom structs? If so, what’s the underlying cause, and is there a specific change we can cherry-pick onto 5.5.4 that addresses it (beyond the graceful-handling mitigation in CL 42772678)? The 5.7 default-off flip suggests the root cause may have been resolved — if there’s a corresponding fix CL, that’s what we most need.
If you have any insights to this issue it would help a lot. Thanks!
[Attachment Removed]