Body:
Describe the bug
Clients on Minecraft 1.21.11 get disconnected ~2 seconds after joining the virtual limbo world (auth/captcha stage via LimboAuth + LimboFilter). Client-side error:
Internal Exception: io.netty.handler.codec.DecoderException: java.io.IOException:
Packet play/clientbound/minecraft:set_chunk_cache_center (class_4282) was larger than
I expected, found 9 bytes extra whilst reading packet clientbound/minecraft:set_chunk_cache_center
Clients on 1.20.x, 1.21.9 etc. connect and pass through limbo fine. Only 1.21.11 is affected. Not related to ViaFabricPlus — tested with a plain Fabric client, no multiversion mod installed.
Environment
LimboAPI: 1.1.27-SNAPSHOT (git-839773c, dev-build)
LimboAuth: 1.1.14
LimboFilter: 1.1.18
Velocity: 3.5.1
ViaVersion + ViaBackwards: 5.11.0
Backend server: Spigot 1.16.5
What I've already ruled out
Compared SET_CHUNK_CACHE_CENTER packet ID between 1.21.9 and 1.21.11 directly in ViaVersion's source (ClientboundPackets1_21_9.java vs ClientboundPackets1_21_11.java) — identical (0x5C), no ID shift between these two versions. Full packet enum diff between the two files shows only one cosmetic rename (HORSE_SCREEN_OPEN → MOUNT_SCREEN_OPEN), no reordering/insertion.
Confirmed via minecraft-data (PrismarineJS) protocol.json for 1.21.9 vs 1.21.11 — packet ID table and outer level_chunk_with_light structure (x, z, heightmaps, chunkData blob, blockEntities, lightmasks, light arrays) are byte-identical between the two versions.
Because the mismatch surfaces on set_chunk_cache_center (the packet right after level_chunk_with_light) rather than inside the chunk packet itself, this looks like a framing/length issue in level_chunk_with_light's opaque chunkData blob rather than the view-position packet itself — the client likely silently over/under-reads the chunk blob (since it's a variable, opaquely-typed byte array from the client's perspective) and only detects the desync on the next strictly-structured packet.
Suspected root cause
The only chunk-section-format branch near this version range that I could find is the fluidCount field in:
NetworkSection.java (write114Data, line ~66/136): only written for version.noLessThan(MINECRAFT_26_1)
ChunkDataPacket.java (emptySectionSize / getDataLength, lines ~247, 259): same threshold
with the comment // TODO: properly set fluidCount, as of 26.1 it is used only to guess about fluid in chunks.
This is internally self-consistent (both the length calculation and the actual write agree for both sides of the 26.1 threshold), so no IndexOutOfBoundsException/warning triggers within LimboAPI itself — but I can't verify from any public protocol dataset whether Mojang actually introduced this field one version earlier, at 1.21.11 rather than 26.1, since the chunk section's internal byte layout isn't part of any public protocol spec I have access to.
What would help confirm this
A raw packet byte diff of level_chunk_with_light sent to a 1.21.9 client vs a 1.21.11 client for the same limbo world/chunk content, to check whether the section byte length differs between the two client versions with identical LimboAPI-side content. I don't have a way to do this myself (no MITM/packet capture setup), but if a maintainer can confirm the actual layout, I'm happy to test a patch shifting the MINECRAFT_26_1 threshold to MINECRAFT_1_21_11 in the three locations above.
Dump: https://dump.viaversion.com/958d44375078004990f8c216fbf417d7c36243ac4f08e6f167fd58c0c2b0c6c4
Body:
Describe the bug
Clients on Minecraft 1.21.11 get disconnected ~2 seconds after joining the virtual limbo world (auth/captcha stage via LimboAuth + LimboFilter). Client-side error:
Internal Exception: io.netty.handler.codec.DecoderException: java.io.IOException:
Packet play/clientbound/minecraft:set_chunk_cache_center (class_4282) was larger than
I expected, found 9 bytes extra whilst reading packet clientbound/minecraft:set_chunk_cache_center
Clients on 1.20.x, 1.21.9 etc. connect and pass through limbo fine. Only 1.21.11 is affected. Not related to ViaFabricPlus — tested with a plain Fabric client, no multiversion mod installed.
Environment
LimboAPI: 1.1.27-SNAPSHOT (git-839773c, dev-build)
LimboAuth: 1.1.14
LimboFilter: 1.1.18
Velocity: 3.5.1
ViaVersion + ViaBackwards: 5.11.0
Backend server: Spigot 1.16.5
What I've already ruled out
Compared SET_CHUNK_CACHE_CENTER packet ID between 1.21.9 and 1.21.11 directly in ViaVersion's source (ClientboundPackets1_21_9.java vs ClientboundPackets1_21_11.java) — identical (0x5C), no ID shift between these two versions. Full packet enum diff between the two files shows only one cosmetic rename (HORSE_SCREEN_OPEN → MOUNT_SCREEN_OPEN), no reordering/insertion.
Confirmed via minecraft-data (PrismarineJS) protocol.json for 1.21.9 vs 1.21.11 — packet ID table and outer level_chunk_with_light structure (x, z, heightmaps, chunkData blob, blockEntities, lightmasks, light arrays) are byte-identical between the two versions.
Because the mismatch surfaces on set_chunk_cache_center (the packet right after level_chunk_with_light) rather than inside the chunk packet itself, this looks like a framing/length issue in level_chunk_with_light's opaque chunkData blob rather than the view-position packet itself — the client likely silently over/under-reads the chunk blob (since it's a variable, opaquely-typed byte array from the client's perspective) and only detects the desync on the next strictly-structured packet.
Suspected root cause
The only chunk-section-format branch near this version range that I could find is the fluidCount field in:
NetworkSection.java (write114Data, line ~66/136): only written for version.noLessThan(MINECRAFT_26_1)
ChunkDataPacket.java (emptySectionSize / getDataLength, lines ~247, 259): same threshold
with the comment // TODO: properly set fluidCount, as of 26.1 it is used only to guess about fluid in chunks.
This is internally self-consistent (both the length calculation and the actual write agree for both sides of the 26.1 threshold), so no IndexOutOfBoundsException/warning triggers within LimboAPI itself — but I can't verify from any public protocol dataset whether Mojang actually introduced this field one version earlier, at 1.21.11 rather than 26.1, since the chunk section's internal byte layout isn't part of any public protocol spec I have access to.
What would help confirm this
A raw packet byte diff of level_chunk_with_light sent to a 1.21.9 client vs a 1.21.11 client for the same limbo world/chunk content, to check whether the section byte length differs between the two client versions with identical LimboAPI-side content. I don't have a way to do this myself (no MITM/packet capture setup), but if a maintainer can confirm the actual layout, I'm happy to test a patch shifting the MINECRAFT_26_1 threshold to MINECRAFT_1_21_11 in the three locations above.
Dump: https://dump.viaversion.com/958d44375078004990f8c216fbf417d7c36243ac4f08e6f167fd58c0c2b0c6c4