serializer, http, grpc: default inbound size limits to warn-only - #3576
Merged
Conversation
#### Motivation The inbound message-size limits (gRPC maxInboundMessageSize, HTTP maxAggregatedPayloadSize, and the streaming serializer frame limit) each defaulted to enforcing a 4 MiB cap and rejecting oversized messages. To ease rollout, the built-in default should warn rather than reject, so operators can observe the impact before opting into enforcement. #### Modifications - Flip the built-in default of each limit to warn-only (-1): an oversized message is delivered but a rate-limited (once per 5 min) warning is logged. This covers MessageSizeLimiter (serializer-utils), HttpConfig (http-netty), and GrpcMessageSizeLimiter (grpc-api). - Enforcement stays opt-in: a positive value via the builder enforces (0 disables), and the temporary system property still accepts a positive value, 0, or -1. The property now seeds the warn-only default, so only log the "temporary property" notice when it is actually set. - Update the javadoc, website docs, and tests. #### Result Out of the box, an oversized inbound message is logged (rate-limited) rather than rejected. Enforcement remains one builder call (or system property) away. #### Behavior change Reverses the 4 MiB default from enforcing to warn-only. Deployments relying on the default to reject oversized messages must now enforce explicitly via maxInboundMessageSize(int) / maxAggregatedPayloadSize(int) (or the temporary system property).
| /** | ||
| * Singleton instance which creates <a href="https://developers.google.com/protocol-buffers/">protocol buffer</a> | ||
| * serializers, applying the default maximum streaming message size. | ||
| * serializers; its streaming deserializers warn (rate-limited), rather than rejecting, when a message exceeds the |
Member
There was a problem hiding this comment.
Javadoc is part of public API. If users read it once, they unlikely to re-read it. That's the main reason why for a long time we tried to avoid clarifying default values in javadoc, as we could change some.
As the warn-only will be a temporary behavior, we shouldn't rewrite all our docs to say that it's a default behavior. We should either keep docs as they were and only mark in release notes that temporarily we enabling warn-only mode, or we can enhance javadoc for each case to say that warn-only mode is temporary and will change to enforcement soon.
Contributor
Author
There was a problem hiding this comment.
I reverted the javadoc change.
idelpivnitskiy
approved these changes
Jul 20, 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
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.
Motivation
The inbound message-size limits (gRPC maxInboundMessageSize, HTTP maxAggregatedPayloadSize, and the streaming serializer frame limit) each defaulted to enforcing a 4 MiB cap and rejecting oversized messages. To ease rollout, the built-in default should warn rather than reject, so operators can observe the impact before opting into enforcement.
Modifications
Result
Out of the box, an oversized inbound message is logged (rate-limited) rather than rejected. Enforcement remains one builder call (or system property) away.
Behavior change
Reverses the 4 MiB default from enforcing to warn-only.