Minecraft Version

1.19.x

Version

1.103.1

Details

When creating a decompressor with non-default compression parameters, Netty attempts to use jzlib rather than the built-in JDK zlib implementation:

https://github.com/netty/netty/blob/cf5c467f4ead5ba5e1e36f5c4903af78bd49c35c/codec/src/main/java/io/netty/handler/codec/compression/ZlibCodecFactory.java#L78-L84

However, we do not bundle jzlib with the jar, and so this throws an exception. This in turn is then swallowed (I think, we should check where it ends up at least!), but results in an empty message being sent to the client.

Our best bet here is probably to bundle jzlib in the jar. I don't think it'll have a massive effect on jar size, but we should check.

Ahhh, this is going to require us switching Forge over to use jar-in-jar - we can't relocate jzlib as it's used in netty-codec (which is shipped as part of Minecraft) rather than just in netty-codec-http.

If we do switch over to jar-in-jar, we should look at how consuming the published artifact works. fg.deobf strips transitive dependencies, so ideally we'd publish the jar with everything bundled inside it (though MinecraftForge/ForgeGradle#914 is blocking that right now), however the docs suggest that's not recommended, so probably need to ask on Discord instead.