fix(ext/node): keep v8.serialize output readable by Node.js#35118
Merged
Conversation
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
1 participant
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.
The V8 14.9 upgrade in Deno 2.8.0 bumped V8's ValueSerializer wire format
version from 15 to 16 (64-bit ArrayBuffer lengths). The format is not
forwards-compatible and no released Node.js or Electron can read version
16, so any
v8.serializeoutput crossing the Deno -> Node.js boundary nowthrows "Unable to deserialize cloned data due to invalid or unsupported
version" on the Node.js side. This broke the Vitest VS Code extension,
whose extension-host RPC v8-serializes every message exchanged with the
deno -A worker.jsprocess it spawns: the JSON handshake succeeds, thenthe first serialized RPC response is rejected and test discovery stalls
forever.
For payloads smaller than 4GB the version 16 byte stream is identical to
version 15 except for the version byte in the header (length fields are
varints either way, and varint<size_t> equals varint<uint32_t> for values
below 2^32), so the serializer now relabels the header as version 15 when
the output is below 4GB. Larger outputs keep the version 16 header since
they cannot be represented in version 15 at all.
Fixes #35113