test: Fix flaky L0_http test_large_string_in_json

[Vinya567]

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-size guard, but that body produces a Content-Length header beyond INT32_MAX. After the recent std::atoi → std::stoi change in Content-Length parsing (#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

• PR title reflects the change and is of format <type>: <description>
• Changes are described in the pull request.
• Related issues are referenced.
• Populated github labels field
• Added test plan and verified test passes.
• Verified that the PR passes existing CI.
• Verified copyright is correct on all changed files.
• Added succinct git squash message before merging ref.
• All template sections are filled out.
• Optional: Additional screenshots for behavior/output changes with before/after.

Commit Type:

• test

Related PRs:

• fix: Replace std:atoi with std:stoi #8794 — the upstream std::atoi → std::stoi change in Content-Length parsing that exposed the latent issue. Before this change, atoi silently returned a wrong-but-non-throwing value on overflow, so the test happened to still reach the JSON-size check. After, stoi throws and the server returns a different error than the test expects.
• fix: Improve input size validation for large HTTP JSON requests #8432 — the original PR that introduced 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_payload_of_json_size helper and the rewritten test_large_string_in_json.

Test plan:

Verified locally in a triton-devel container against main:

• InferSizeLimitTest.test_large_string_in_json — 10/10 pass
• Full qa/L0_http/test.sh — passes, no other regressions

The new test asserts both sides of the boundary:

• Body of exactly DEFAULT_LIMIT_BYTES (64 MiB) → must succeed (200)
• Body of DEFAULT_LIMIT_BYTES + 1 → must fail with the JSON-size error

Body length is asserted byte-exact in the helper via assertEqual(len(json.dumps(payload)), target_size) before being posted with requests.post(json=payload), so the boundary is byte-precise and not skewed by JSON wrapper overhead.

• CI Pipeline ID: 53762086 — targeted run via RULE_WORKFLOW + EXTRA_BUILD_BACKENDS=python onnxruntime per reviewer tips. L0_http--base job retried for commit f9b4e0b: https://gitlab-master.nvidia.com/dl/dgx/tritonserver/-/jobs/334699597 — passed in 8 min 29 sec, no rebuild needed for test-only change.

test_chunked_infer_over_max_chunks_reject_with_bounded_rss_growth (in qa/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_json was added to verify the server's --http-max-input-size JSON-body limit. The original test built a body large enough to clearly exceed the default 64 MiB limit, but also large enough that the resulting Content-Length header overflows a signed 32-bit integer (Content-Length: 2147483796 vs INT32_MAX = 2147483647).

Before #8794, Content-Length was parsed with std::atoi, which silently returned an undefined-but-non-throwing value on overflow, so the body still reached the JSON-size check. After #8794 switched to std::stoi, that parse now throws std::out_of_range and the server returns 400 with:

Unable to parse Content-Length, value is out of range [ -2147483648, 2147483647 ], got: 2147483796

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:

• Relates to fix: Replace std:atoi with std:stoi #8794
• Relates to fix: Improve input size validation for large HTTP JSON requests #8432

[yinggeh]

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.

[yinggeh]

Again, do not put linear tickets in public PRs.

[Vinya567]

Both addressed:

• PR description rewritten to use pull_request_template_internal_contrib.md all template sections filled out.
• Scrubbed all Linear / internal references (description, title, etc.).

Sorry for the slip ,added both rules to my onboarding checklist so they don't happen again. Thanks for the catches!

[pskiran1]

LGTM

[yinggeh]

Left some comments

[yinggeh]

LGTM