Repository navigation
Fix Unicode truncation of HTTP error bodies - #26
Open
agocharbhatia wants to merge 1 commit into
Open
agocharbhatia wants to merge 1 commit into
agocharbhatia wants to merge 1 commit into
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
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.
Long HTTP error bodies can panic in the Rust SDK when byte 4096 falls inside a UTF-8 character. This interrupts error reporting and can prevent a retryable response from reaching the next attempt.
Truncate the decoded body in place at the nearest preceding character boundary, retaining the existing 4096-byte limit. The boundary adjustment examines at most three bytes and works on Rust 1.88.
Two HTTP integration regressions cover short/exact-limit bodies, ASCII overflow, every interior cutoff in two-, three-, and four-byte characters, 400/503 status preservation, and a long Unicode 503 followed by a successful retry. Both new tests panic against the unchanged upstream implementation and pass with this fix.
Validation (local mock servers, no live API):
Parallel unit-test runs hit existing Git-process timing assertions, also reproduced with unchanged upstream source. All 48 pass serially. No timing tests are changed here.