[BugFix] Allow request body cap to be set via MAX_REQUEST_BUFFER_BYTES#10
Merged
bhuvan-teja-glean merged 2 commits intoJun 11, 2026
Conversation
ashish-kumar-glean
changed the title
ashish-kumar-glean
force-pushed
the
ashish/configurable-max-request-buffer
branch
from
23f1d44 to
39a8862
Compare
pooja-bhagat-glean
approved these changes
May 29, 2026
The hard-coded 5 MB cap in getMaximumRequestBufferSizeInBytes() makes Netty's HttpObjectAggregator reject any request body over 5 MB with HTTP 413 before any filter runs. This breaks customer flows such as /api/index/v1/indexdocuments where payloads commonly exceed 5 MB (e.g. Ericsson sending ~28 MB documents). Read the cap from MAX_REQUEST_BUFFER_BYTES (positive integer, bytes) and default to 64 MB. Invalid or non-positive values log a warning and fall back to the default. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per review feedback, leave the default cap unchanged so existing deployments behave identically. Customers needing larger payloads (e.g. Ericsson on /api/index/v1/indexdocuments) set MAX_REQUEST_BUFFER_BYTES explicitly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ashish-kumar-glean
force-pushed
the
ashish/configurable-max-request-buffer
branch
from
39a8862 to
31bedf8
Compare
bhuvan-teja-glean
approved these changes
Jun 9, 2026
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
3 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.
Description:
DynamicHttpFiltersSourceAdapter.getMaximumRequestBufferSizeInBytes()is hard-coded to 5 MB, which becomes themaxContentLengthLittleProxy passes to Netty'sHttpObjectAggregator. Any request body above 5 MB is rejected with HTTP 413 inside the aggregator before any filter runs.This change reads the cap from a new
MAX_REQUEST_BUFFER_BYTESenv var (positive integer, bytes). When unset/invalid/non-positive, it falls back to the existing 5 MB default — so existing deployments are unaffected. Customers who need a larger cap (e.g. for/api/index/v1/indexdocuments) set the env var explicitly.Context: Ericsson on-prem proxy traffic to
/api/index/v1/indexdocumentswas returning 413 for ~28 MB document payloads, while the same request worked when bypassing the proxy and hitting DSE directly. Root cause was the hard-coded 5 MB cap; DSE itself does not enforce an HTTP body-size limit at the framework level.Test plan: End-to-end repro and fix verified in
sa-sandboxproxy VM (10.50.0.20) fromaws-salessavvy-testtest VM via TGW.With the patched JAR deployed and
MAX_REQUEST_BUFFER_BYTES=67108864(64 MB):(The 400 in the post-fix column is the proxy's own URI-routing rejection downstream of aggregation, because the repro path bypasses the inbound NLB and doesn't carry full auth context — irrelevant to the size-cap bug; what matters is that
uploadnow matches the file size.)Also confirmed the patched class is what's actually running by extracting
DynamicHttpFiltersSourceAdapter.classfrom the JAR inside the container and verifying the new symbols (MAX_REQUEST_BUFFER_BYTES,resolveMaxRequestBufferBytes,DEFAULT_MAX_REQUEST_BUFFER_BYTES) are present in the bytecode.With the env var unset, the cap stays at 5 MB exactly as before.
Change Type
Platform (Choose one if applicable)