Support ext formats in MessageLen and report limit violations as ParseError - #388
Open
baszalmstra wants to merge 4 commits into
Open
Support ext formats in MessageLen and report limit violations as ParseError#388baszalmstra wants to merge 4 commits into
baszalmstra wants to merge 4 commits into
Conversation
(cherry picked from commit c2dcea9)
Extends the ext coverage from the previous commit with the ext32 format (both a small non-canonical length checked for every prefix, and a canonical 70k payload), the u8/u16 boundary lengths, and ext values inside arrays and maps so that resumption of an interrupted ext inside a sequence is exercised too. Claude-Session: https://claude.ai/code/session_011NAQi5b2wGJsRjiEcCHjZ8
Exceeding the depth or length limit set the LimitExceeded state, but the call that hit it still reported `Truncated(lower_bound)`; only the next call returned `ParseError`. A caller using `len_of` on a complete message therefore saw "needs more data" for an over-limit message, and a streaming caller had to make one extra round trip to learn the message was unparseable. `incremental_len` now reports `ParseError` as soon as a sticky state is entered. A second sticky state, `Reserved`, is added for the reserved marker 0xc1, which every decoder in this repository rejects but MessageLen used to count as a one-byte value. Claude-Session: https://claude.ai/code/session_011NAQi5b2wGJsRjiEcCHjZ8
While the length prefix of an ext8/16/32 value is still being read, the type byte is already known to follow it, so include it in the estimate. Also documents that `max_len` applies to ext payloads and why `len + 1` cannot overflow. Claude-Session: https://claude.ai/code/session_011NAQi5b2wGJsRjiEcCHjZ8
baszalmstra
force-pushed
the
est-ext-limits
branch
from
August 31, 2026 10:05
17db045 to
698e2b6
Compare
baszalmstra
marked this pull request as ready for review
August 31, 2026 10:06
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
2 participants
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.
Builds on #374 by @eggyal (cherry-picked as the first commit, please keep the credit) and adds a few things I ran into while trying to use
MessageLento find the end of a value:Truncated(n)on the call that hit them;ParseErroronly showed up on the next call. Solen_ofon a complete over-limit message said "needs more data". It is nowParseErrorright away, and sticky untilreset().0xc1counted as a one-byte value. Every decoder in this repo rejects it, soMessageLennow does too. This is a behaviour change, happy to drop it if you'd rather keep this lenient.Each follow-up commit adds its tests first, so it should be easy to review them one by one.
cargo test --workspacepasses.