fix(thrift): sign-extend negative I64 on read; support bigint/BOOL/BYTE/I16 collection elements - #217
Open
nezumi0627 wants to merge 1 commit into
Open
Conversation
…TE/I16 collection elements
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
Four related correctness bugs in the Thrift read/write layer, each verified with a failing round-trip before the fix:
1. Negative I64 values decoded as huge positive numbers (
read.ts)The reader interpreted raw two's-complement octets as an unsigned hex number:
The write side was already fixed for negatives (
asUintN, pinned bywrite.test.ts:-5n→fffffffffffffffbon the wire), but a round-trip failed: reading-5nback gave18446744073709551611n. The reader now sign-extends when the top bit is set.2. bigint I64 rejected inside LIST/SET/MAP elements (
write.ts)The #193 fix (bigint-safe Int64 encoding) was only applied to field-level
writeValue. Collection elements go throughwriteValue_, which threw:This matters for e.g. message IDs passed as list elements.
writeValue_now mirrors the field-level encoding.3. BYTE (3) and I16 (6) fields silently dropped / corrupt frames
Both types are declared in
NestedArraybut fell through todefault:in both writers — no error, no bytes:[[3, 1, 255]]produced an empty struct (field vanished silently).writeListBegin(etype=3, count=3)was written and then nothing per element, producing a structurally corrupt frame that claims 3 elements.readValuereturnedundefined).BYTE/I16 are now written and read properly on both sides.
4. BOOL accepted numbers at field level but not element level
writeValueacceptsboolean | number,writeValue_required strictboolean. Now consistent.Testing
18446744073709551611n; bigint element threw; BYTE field absent from wire; BYTE list emitted count=3 with zero elements).write.test.ts(5 new tests): negative-I64 round-trip on both protocols, bigint-in-collection encoding, BYTE/I16 field wire hex pin, BYTE/I16 collection round-trip, numeric-BOOL acceptance.deno test --allow-all— 219 passed, 0 failed.deno fmt/deno lintclean on touched files.