feat(ci): raise junit upload soft cap to 20 MiB - #1735
Merged
mergify[bot] merged 1 commit intoJul 21, 2026
Conversation
Raise the client-side gzipped upload soft cap (the per-chunk split target in junit_process::split) from 10 MiB to 20 MiB. This cap is a client-side split target, not the server's limit: the ingest endpoint hard-caps gzipped payloads at 25 MiB (MRGFY-8124), so sizing each chunk under 20 MiB leaves 5 MiB of headroom below the 413 rejection threshold. Larger chunks mean fewer, larger uploads for big reports (WiseTech Global case): a 20 MiB gzipped chunk holds roughly 120 MiB of raw JUnit XML worst-case (stacktrace-heavy), up to ~190 MiB for passing-heavy reports. The doc comment is rewritten to describe the soft/hard split, dropping the old wording that implied the CLI cap was itself the endpoint's refusal threshold. A compile-time assertion mirrors the backend's 25 MiB hard cap and enforces the 5 MiB headroom: since the two limits live in separate services linked only by prose, a future bump that crossed the hard cap would otherwise ship silently and 413-drop every over-cap chunk. Now it breaks the build instead. Existing split tests inject their own small cap, so they are unaffected by the constant's value. Blocked by MRGFY-8124: must not deploy before the backend 25 MiB hard cap is live. With the server still at 10 MiB, chunks in the 10-20 MiB range would 413 and their data would be dropped. Ships as a draft until the backend is deployed. Fixes MRGFY-8125 Change-Id: I1e4216324244f3c3da004b9b86c7b28591c5df73
Contributor
Merge Protections🟢 All 6 merge protections satisfied — ready to merge. Show 6 satisfied protections🟢 🤖 Continuous Integration
🟢 👀 Review Requirements
🟢 Enforce conventional commitMake sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
🟢 🔎 Reviews
🟢 📕 PR description
🟢 🚦 Auto-queueWhen all merge protections are satisfied, this pull request will be queued automatically. |
sileht
marked this pull request as ready for review
July 21, 2026 12:10
There was a problem hiding this comment.
Pull request overview
Updates the mergify ci junit-process upload chunk sizing to reduce the number of OTLP uploads for large JUnit reports, while keeping client-side chunks safely below the ingest service’s hard gzip payload limit.
Changes:
- Raise
MAX_GZIPPED_UPLOAD_BYTES(client-side split target) from 10 MiB to 20 MiB. - Rewrite the doc comment to clarify the “soft cap” (client target) vs the backend “hard cap”.
- Add a compile-time assertion enforcing 5 MiB headroom under the mirrored 25 MiB backend hard cap.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
JulianMaurin
approved these changes
Jul 21, 2026
kozlek
approved these changes
Jul 21, 2026
Contributor
Merge Queue Status
This pull request spent 55 seconds in the queue, including 7 seconds running CI. Required conditions to merge
|
mergify
Bot
deleted the
devs/sileht/mrgfy-8125-cli-soft-cap-20mib/raise-junit-upload-soft-cap-20-mib--1e421632
branch
July 21, 2026 13:13
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.
Raise the client-side gzipped upload soft cap (the per-chunk split
target in junit_process::split) from 10 MiB to 20 MiB.
This cap is a client-side split target, not the server's limit: the
ingest endpoint hard-caps gzipped payloads at 25 MiB (MRGFY-8124), so
sizing each chunk under 20 MiB leaves 5 MiB of headroom below the 413
rejection threshold. Larger chunks mean fewer, larger uploads for big
reports (WiseTech Global case): a 20 MiB gzipped chunk holds roughly
120 MiB of raw JUnit XML worst-case (stacktrace-heavy), up to ~190 MiB
for passing-heavy reports.
The doc comment is rewritten to describe the soft/hard split, dropping
the old wording that implied the CLI cap was itself the endpoint's
refusal threshold.
A compile-time assertion mirrors the backend's 25 MiB hard cap and
enforces the 5 MiB headroom: since the two limits live in separate
services linked only by prose, a future bump that crossed the hard cap
would otherwise ship silently and 413-drop every over-cap chunk. Now
it breaks the build instead. Existing split tests inject their own
small cap, so they are unaffected by the constant's value.
Blocked by MRGFY-8124: must not deploy before the backend 25 MiB hard
cap is live. With the server still at 10 MiB, chunks in the 10-20 MiB
range would 413 and their data would be dropped. Ships as a draft
until the backend is deployed.
Fixes MRGFY-8125