test: Fix flaky L0_http test_large_string_in_json#8819
Open
Vinya567 wants to merge 3 commits into
Open
Conversation
Use a payload just over the 64MB default limit instead of ~2GB so the server returns the expected JSON size error rather than rejecting the request at INT32 Content-Length parsing.
Per Yingge's review feedback on the initial fix: - Use byte-precise +1 boundary instead of OFFSET_ELEMENTS (32 bytes). - Add complementary "exactly at limit succeeds" case so the test guards both sides of the boundary, matching the pattern used by test_default_limit_raw_binary. Body is constructed manually with json.dumps and posted with data= so the total HTTP body length is exact (no wrapper-overhead drift).
yinggeh
reviewed
Jun 5, 2026
Contributor
|
If you are using agent generating PR description, make sure tell it to use https://github.com/triton-inference-server/server/blob/main/.github/PULL_REQUEST_TEMPLATE/pull_request_template_internal_contrib.md as the template. |
Contributor
|
Again, do not put linear tickets in public PRs. |
- Rename _build_string_body_of_size -> _build_json_string_body_of_size (more specific name, JSON is the operative format) - Drop PR-specific commentary from the test docstring and inline comments; keep only documentation that's useful when reading the test itself Per review on #8819.
Contributor
Author
|
Both addressed:
Sorry for the slip ,added both rules to my onboarding checklist so they don't happen again. Thanks for the catches! |
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.
What does the PR do?
Fixes a deterministic failure in
qa/L0_http/http_input_size_limit_test.py::test_large_string_in_json.The test built a ~2 GiB JSON body to exercise the server's
--http-max-input-sizeguard, but that body produces aContent-Lengthheader beyondINT32_MAX. After the recentstd::atoi→std::stoichange inContent-Lengthparsing (#8794), the server now rejects the request at the header-parse step (with an INT32 range error) before ever reaching the JSON-size check the test asserts on, so the test fails on every nightly.The fix shrinks the request body to byte-precise boundaries around the JSON-size limit, so the test actually exercises the guard it claims to.
Checklist
<type>: <description>Commit Type:
Check the conventional commit type
box here and add the label to the github PR.
Related PRs:
std::atoi→std::stoichange inContent-Lengthparsing that exposed the latent issue. Before this change,atoisilently returned a wrong-but-non-throwing value on overflow, so the test happened to still reach the JSON-size check. After,stoithrows and the server returns a different error than the test expects.test_large_string_in_json. /cc @spolisetty for design intent on the original 2 GiB sizing.Where should the reviewer start?
qa/L0_http/http_input_size_limit_test.py— the change is contained to one file. Look at the new_build_json_string_body_of_sizehelper and the rewrittentest_large_string_in_json.Test plan:
Verified locally in a
triton-develcontainer againstmain:InferSizeLimitTest.test_large_string_in_json— 10/10 passqa/L0_http/test.sh— passes, no other regressionsThe new test asserts both sides of the boundary:
DEFAULT_LIMIT_BYTES(64 MiB) → must succeed (200)DEFAULT_LIMIT_BYTES + 1→ must fail with the JSON-size errorBody length is constructed exactly (manual
json.dumps+ posted withdata=) so the boundary is byte-precise and not skewed by JSON wrapper overhead. Pattern mirrors the existing both-sidestest_default_limit_raw_binary.Caveats:
test_chunked_infer_over_max_chunks_reject_with_bounded_rss_growth(inqa/L0_http/http_request_many_chunks.py) also occasionally fails in nightly runs with intermittent RSS-growth assertions (4.2 MiB > 1 MiB). That failure is intermittent, unrelated to this fix, and should be tracked separately.Background
test_large_string_in_jsonwas added to verify the server's--http-max-input-sizeJSON-body limit. The original test built a body large enough to clearly exceed the default 64 MiB limit, but also large enough that the resultingContent-Lengthheader overflows a signed 32-bit integer (Content-Length: 2147483796vsINT32_MAX = 2147483647).Before #8794,
Content-Lengthwas parsed withstd::atoi, which silently returned an undefined-but-non-throwing value on overflow, so the body still reached the JSON-size check. After #8794 switched tostd::stoi, that parse now throwsstd::out_of_rangeand the server returns 400 with:which doesn't match the JSON-size error the test expects. The fix keeps the test focused on the JSON-size guard by constructing a body just at and just above the limit (well below INT32 Content-Length).
Related Issues: