Use sync zlib in packet compression to avoid uncaught errors#1476
Merged
Use sync zlib in packet compression to avoid uncaught errors#1476
Conversation
0590212 to
e79bb4f
Compare
rom1504
added a commit
to PrismarineJS/mineflayer
that referenced
this pull request
Mar 31, 2026
Points to PrismarineJS/node-minecraft-protocol#fix-zlib-node24 which uses sync zlib (deflateSync/unzipSync) to prevent uncaught async zlib errors on Node 24. See PrismarineJS/node-minecraft-protocol#1476 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
cbafadb to
79e3412
Compare
Node's async zlib (deflate/unzip) creates internal C++ Zlib handles
that run on the libuv thread pool. When a client disconnects while
decompression is in progress, the C++ callback fires after the JS
error listener is removed, causing an uncaught exception:
Uncaught Error: unexpected end of file
at Zlib.zlibOnError [as onerror]
This is a known Node.js issue — see:
- nodejs/node#62325 (use-after-free fix for reset during write)
- nodejs/node#61202 (zlib stream corruption with multiple instances)
- nodejs/node#43868 (uncaught zlib exception in fetch)
Switch to deflateSync/unzipSync which complete synchronously with no
lingering C++ handles. Each call processes one MC packet (~few KB),
so event loop impact is negligible.
Also wrap gunzipSync in minecraft.js NBT parsing with try/catch.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Member
Author
|
/makerelease |
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Switch from async zlib (deflate/unzip) to sync (deflateSync/unzipSync) in packet compression.
Why
Node's async zlib creates internal C++ Zlib handles that run on the libuv thread pool. When a client disconnects while decompression is in progress, the C++ callback fires after the JS error listener is removed, causing an uncaught exception:
This is a known Node.js issue:
Why sync is safe here
Each call processes one Minecraft packet (~few KB). The event loop impact is negligible. Sync calls complete immediately with no lingering C++ handles, eliminating the race condition entirely.
Performance (no slowdown)
Within noise — no measurable difference.
Changes
compression.js: deflateSync/unzipSync with try/catchminecraft.js: try/catch around existing gunzipSync in NBT parsing🤖 Generated with Claude Code