UDP decode error spam.

[sharkk2]

Description

The logs are being spammed every ping with UDP Decode failure

[16:44:26 ERROR]: Failed to decode UDP packet of type SNAPSHOT from /163.5.201.9:48718 java.lang.IndexOutOfBoundsException: readerIndex(31) + length(8) exceeds writerIndex(33): PooledSlicedByteBuf(ridx: 31, widx: 33, cap: 33/33, unwrapped: PooledUnsafeDirectByteBuf(ridx: 0, widx: 33, cap: 2048))

Game Log

https://mclo.gs/tZQ07Kc

[zanderson88]

Additional repro/data point from a 1.21.1 NeoForge dedicated server running Sable 1.2.2.

Summary

We are seeing the same Failed to decode UDP packet of type SNAPSHOT spam on a hosted dedicated server after a player joins/loads chunks. The server experienced what looked like a soft crash/desync from the player side, but the captured server log did not show watchdog, OOM, shutdown, or a normal crash report marker.

The UDP decode error appears repeatedly and always fails while constructing/decoding ClientboundSableSnapshotDualPacket.

Environment

• Minecraft: 1.21.1
• Loader: NeoForge 21.1.230
• Sable: sable-neoforge-1.21.1-1.2.2.jar
• Server: dedicated hosted server
• Player count during latest capture: 1

Relevant repeated stack trace

[Netty Epoll Server IO #0/ERROR] [de.ry.sa.Sable/]: Failed to decode UDP packet of type SNAPSHOT from /<server-or-peer-ip>:<port>
java.lang.IndexOutOfBoundsException: readerIndex(26|32|33) + length(8) exceeds writerIndex(33): PooledSlicedByteBuf(... cap: 33/33 ...)
    at io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1442)
    at io.netty.buffer.AbstractByteBuf.readLong(AbstractByteBuf.java:835)
    at io.netty.buffer.AbstractByteBuf.readDouble(AbstractByteBuf.java:861)
    at net.minecraft.network.FriendlyByteBuf.readDouble(FriendlyByteBuf.java:1200)
    at dev.ryanhcode.sable.util.SableBufferUtils.read(SableBufferUtils.java:30)
    at dev.ryanhcode.sable.util.SableBufferUtils.read(SableBufferUtils.java:55)
    at dev.ryanhcode.sable.network.packets.ClientboundSableSnapshotDualPacket.readList(ClientboundSableSnapshotDualPacket.java:66)
    at dev.ryanhcode.sable.network.packets.ClientboundSableSnapshotDualPacket.<init>(ClientboundSableSnapshotDualPacket.java:56)
    at net.minecraft.network.codec.StreamCodec$1.decode(StreamCodec.java:20)
    at dev.ryanhcode.sable.network.udp.SableUDPPacketType.create(SableUDPPacketType.java:29)
    at dev.ryanhcode.sable.network.udp.SableUDPPacketDecoder.decode(SableUDPPacketDecoder.java:44)
    at dev.ryanhcode.sable.network.udp.SableUDPPacketDecoder.decode(SableUDPPacketDecoder.java:14)

Counts from two recent log captures

Capture A:

• Raw Failed to decode UDP occurrences: 46
• Unique timestamped Sable UDP events after dedupe: about 27 total unique log entries overall, mostly Sable UDP + unrelated world/chunk warnings
• soulElytraCooldown / Elytra Slot integration errors were also present in this older capture, but appear unrelated and were fixed later.

Capture B, after fixing the Elytra Slot / Deeper and Darker issue:

• Raw Failed to decode UDP occurrences: 41
• Unique Sable UDP decode events after dedupe: about 11
• soulElytraCooldown: 0
• No watchdog / OOM / shutdown / crash-report marker found

So the Sable UDP decode issue persists even after removing the separate Elytra Slot / Deeper and Darker error.

Other context

The same logs also contain unrelated world/mod registry warnings involving visualworkbench:* and twilightforest:* data in chunks. Those may explain the player-side soft crash/desync symptoms, but the Sable UDP decode failures continue independently and repeatedly.

The UDP source address in the server log appears as the server/host address with varying ephemeral ports, so this may involve host NAT/proxy behavior or Sable seeing its UDP path in an unexpected shape on a hosted server.

Impact

• Heavy server log spam while one player is online
• Possible player desync/soft-crash context, though the direct server-side fatal cause is not proven from this log
• Error is reproducible across multiple short log captures

Suggested investigation

ClientboundSableSnapshotDualPacket.readList() / SableBufferUtils.read() should probably validate the remaining readable bytes before reading each vector/double tuple and log packet metadata instead of throwing a full stack trace every time. The packet seems to be consistently 33 bytes long while the decoder sometimes tries to read an additional 8-byte field at reader indexes 26/32/33.

Related issue from the same server, but for a separate crash class: #1162