PBJ Bug: PbjGrpcClientConfig.maxSize Not Respected by PbjGrpcDatagramReader

[AlfredoG87]

Description

Summary

PbjGrpcClientConfig accepts a maxSize parameter (introduced in 0.14.1) intended to allow
clients to receive gRPC responses larger than Codec.DEFAULT_MAX_SIZE (2 MB). However, the
PbjGrpcDatagramReader — which accumulates incoming HTTP/2 DATA frames on the client side —
has a hardcoded MAX_BUFFER_SIZE = 10_485_760 (10 MB) that is never overridden by the
configured maxSize. As a result, any response payload larger than 10 MB throws a
java.nio.BufferOverflowException regardless of the value passed to PbjGrpcClientConfig.

Steps to Reproduce

1. Create a gRPC server that returns a response larger than 10 MB (e.g. a block with TSS Wrap
   items totalling ~30 MB).
2. Create a PbjGrpcClientConfig with maxSize = 37_748_736 (36 MB):

   new PbjGrpcClientConfig(
       Duration.ofMillis(10_000),
       Tls.builder().enabled(false).build(),
       Optional.of(""),
       "application/grpc",
       GrpcCompression.IDENTITY,
       GrpcCompression.getDecompressorNames(),
       37_748_736);

3. Issue a createCall and stream the large response.

Expected: The call succeeds; the response is parsed up to the configured 36 MB limit.
Actual: java.nio.BufferOverflowException in PbjGrpcDatagramReader.ensureCapacity.

Root Cause

In PbjGrpcCall.receiveRepliesLoop, the datagram reader is always constructed with the
no-arg constructor:

// PbjGrpcCall.receiveRepliesLoop (decompiled from pbj-grpc-client-helidon-0.14.1.jar)
PbjGrpcDatagramReader reader = new PbjGrpcDatagramReader();  // maxSize never passed

PbjGrpcDatagramReader.ensureCapacity enforces a hardcoded ceiling:

// PbjGrpcDatagramReader (decompiled — MAX_BUFFER_SIZE = 10_485_760)
if (newCapacity > 10_485_760) {
    throw new BufferOverflowException();
}

The maxSize field on PbjGrpcClientConfig is never read in PbjGrpcCall or
PbjGrpcDatagramReader.

Existing Test That Passes (But Only Because Payload < 10 MB)

The test testUnaryMethodReceivingExtraLargePayload in the PBJ test suite passes because
Codec.DEFAULT_MAX_SIZE * 2 = 4_194_304 (4 MB), which is under the 10 MB cap:

final String extraLongString = "a".repeat(Codec.DEFAULT_MAX_SIZE * 2); // 4 MB — under 10 MB cap
final GrpcClient grpcClient = GrpcTestUtils.createGrpcClient(
    port.port(),
    GrpcTestUtils.PROTO_OPTIONS,
    GrpcCompression.IDENTITY,
    GrpcCompression.getDecompressorNames(),
    Codec.DEFAULT_MAX_SIZE * 2);

The same test would fail if the payload were, say, Codec.DEFAULT_MAX_SIZE * 10 (20 MB).

Suggested Fix

Pass maxSize from PbjGrpcClientConfig into PbjGrpcDatagramReader:

// In PbjGrpcCall constructor or receiveRepliesLoop:
PbjGrpcDatagramReader reader = new PbjGrpcDatagramReader(config.maxSize());

And update PbjGrpcDatagramReader to use the provided limit instead of the hardcoded constant:

// PbjGrpcDatagramReader
private final int maxBufferSize;

PbjGrpcDatagramReader(int maxBufferSize) {
    this.maxBufferSize = maxBufferSize;
}

private void ensureCapacity(int required) {
    // ...
    if (newCapacity > maxBufferSize) {
        throw new BufferOverflowException();
    }
    // ...
}

Affected Version

• pbj-grpc-client-helidon 0.14.1
• Blocks receiving any single gRPC message > 10 MB, regardless of maxSize configuration.

Workaround

None available within PBJ 0.14.1. Callers needing > 10 MB responses must wait for a fix or
send large payloads in multiple smaller gRPC frames (< 10 MB each).

Steps to reproduce

Repeat the Test with a 36MB size message

Additional context

No response

Hedera network

No response

Version

v0.14.1

Operating system

None

[Serhan-Asad]

Step 1: Duplicate Check

Status: No duplicates found

Search Performed

• Searched for: maxSize PbjGrpcDatagramReader, BufferOverflowException grpc, MAX_BUFFER_SIZE, maxSize large payload, PbjGrpcCall datagram, 10MB grpc limit, grpc client config, buffer size grpc, ensureCapacity
• Issues reviewed: 4 (including Make maxSize configurable #637, Helidon gRPC client omits :authority pseudo-header #656, Add support to the Helidon plugin for HTTP2 flow control #454)

Findings

The closest related issue is #637 ("Make maxSize configurable"), which was closed after adding maxSize support to Codec.parse() and PbjGrpcClientConfig in v0.14.1. However, #637 addressed a different layer — it made the codec-level parsing limit configurable.

Issue #756 is a distinct follow-up bug: the maxSize value configured in PbjGrpcClientConfig is never propagated to PbjGrpcDatagramReader, which retains a hardcoded 10 MB MAX_BUFFER_SIZE ceiling. This means the fix from #637 is incomplete — the transport layer still enforces its own limit that cannot be overridden by the client configuration.

This is a new issue and should proceed with investigation.

---

Proceeding to Step 2: Documentation Check

[Serhan-Asad]

[Serhan-Asad]

Step 2: Documentation Check

Status: Confirmed Bug

Documentation Reviewed

• Repository README.md and pbj-grpc-helidon module README
• PbjGrpcClientConfig.java javadoc (@param maxSize the maximum size of messages that the client is able to receive, defaults to Codec.DEFAULT_MAX_SIZE)
• PbjGrpcDatagramReader.java source and inline comments (// These are arbitrary limits, but they seem sane and support the immediate use-case. It would be nice to make them configurable in the future.)
• PbjGrpcCall.java receiveRepliesLoop method
• Issue Make maxSize configurable #637 (original maxSize configurability feature) and its implementation
• Test testUnaryMethodReceivingExtraLargePayload

Findings

The maxSize parameter is explicitly documented as controlling "the maximum size of messages that the client is able to receive." Users have a reasonable expectation that setting this value will allow receiving messages up to that size.

However, the implementation from issue #637 was incomplete — it only propagated maxSize to the codec parsing layer (Codec.parse()), but never to PbjGrpcDatagramReader, which enforces its own hardcoded 10 MB buffer ceiling. The PbjGrpcDatagramReader source code itself acknowledges this gap with the comment: "It would be nice to make them configurable in the future."

Key evidence:

• PbjGrpcCall.receiveRepliesLoop creates new PbjGrpcDatagramReader() with zero-arg constructor — config.maxSize() is never passed
• PbjGrpcDatagramReader.MAX_BUFFER_SIZE is a hardcoded 10 * 1024 * 1024 (10 MB) constant
• The existing test (testUnaryMethodReceivingExtraLargePayload) only uses a 4 MB payload, which is under the 10 MB cap, so it never exercises this code path
• No documentation mentions the 10 MB transport-layer limitation as expected behavior

This is a confirmed bug: the documented API contract (maxSize controls max receivable message size) is violated by the hardcoded transport buffer limit.

---

Proceeding to Step 3: Triage

[Serhan-Asad]

Step 3: Triage

Status: Proceed

Summary

This issue has excellent reproduction information and a clear root cause analysis:

• Expected behavior: PbjGrpcClientConfig.maxSize should control the maximum receivable gRPC message size, allowing responses larger than the default 10 MB limit.
• Actual behavior: PbjGrpcDatagramReader enforces a hardcoded MAX_BUFFER_SIZE = 10_485_760 (10 MB), throwing BufferOverflowException for any payload exceeding that limit regardless of the configured maxSize.
• Reproduction steps: Well-defined — create a gRPC server returning >10 MB response, configure client with a higher maxSize, observe the exception.
• Code area identified: PbjGrpcCall.receiveRepliesLoop constructs PbjGrpcDatagramReader with the no-arg constructor, never passing through config.maxSize(). The existing test (testUnaryMethodReceivingExtraLargePayload) only exercises a 4 MB payload, which is under the 10 MB hardcoded cap.

The issue author provided decompiled code snippets confirming the gap between configuration and enforcement. Steps 1-2 corroborated this analysis against the actual source code.

---

Proceeding to Step 4: Reproduction

[Serhan-Asad]

Step 4: External API Research

External API Dependencies Found

Service	Endpoint/Query	Auth Type	Scopes/Permissions
None	N/A	N/A	N/A

No external API dependencies were identified in the affected code path.

Analysis

The bug exists entirely within the internal gRPC client plumbing of the pbj-grpc-client-helidon module:

1. PbjGrpcClientConfig — accepts maxSize parameter (configuration layer)
2. PbjGrpcCall.receiveRepliesLoop — constructs PbjGrpcDatagramReader without passing maxSize (orchestration layer)
3. PbjGrpcDatagramReader.ensureCapacity — enforces hardcoded MAX_BUFFER_SIZE = 10_485_760 (buffer management layer)

This is a pure internal configuration propagation bug — maxSize is accepted at the config boundary but never threaded through to the component that enforces the size limit. No external HTTP requests, REST APIs, GraphQL queries, or third-party SDK calls are involved in the affected code path.

The gRPC communication itself is direct client-to-server over HTTP/2, using standard Java NIO buffers — no intermediary services, API gateways, or auth-gated endpoints are in the path.

Auth-Type Limitations

• Not applicable. No external authenticated API calls are made in the affected code path.

Permission Scope Analysis

• Not applicable. The bug is caused by a hardcoded constant in internal buffer management code, not by any permission or authentication issue.

Impact on Bug Investigation

External APIs can be ruled out as a contributing factor. The root cause is confirmed as an internal code issue: the maxSize value from PbjGrpcClientConfig is never passed to PbjGrpcDatagramReader, which independently enforces a 10 MB ceiling via MAX_BUFFER_SIZE. The fix requires threading the configured value through PbjGrpcCall into the datagram reader constructor.

---

Proceeding to Step 5: Reproduction

[Serhan-Asad]

Step 5: Reproduction

Status: Reproduced (via static analysis and code path tracing)

Environment

• Java 23.0.2
• PBJ source: latest main branch (version 0.12.0-SNAPSHOT)
• macOS Darwin 24.3.0

Steps Taken

1. Cloned the hashgraph/pbj repository and located all affected files
2. Traced the code path from PbjGrpcClientConfig.maxSize through PbjGrpcCall.receiveRepliesLoop to PbjGrpcDatagramReader.ensureCapacity
3. Confirmed the no-arg constructor usage and hardcoded buffer limit
4. Verified the existing test only passes because its payload (4 MB) is under the 10 MB cap

Observed Behavior

The bug is confirmed through code path analysis:

1. PbjGrpcClientConfig accepts maxSize (line 40) — e.g. 36 MB
2. In PbjGrpcCall.receiveRepliesLoop() (line 177), PbjGrpcDatagramReader is constructed with the no-arg constructor — maxSize is never passed
3. PbjGrpcDatagramReader.ensureCapacity() (line 164) enforces MAX_BUFFER_SIZE = 10 * 1024 * 1024 (10 MB) — any buffer growth beyond this throws BufferOverflowException
4. The maxSize from config is only used at PbjGrpcCall.java:216 for codec parsing depth, never for the datagram reader's buffer limit

The existing test testUnaryMethodReceivingExtraLargePayload uses Codec.DEFAULT_MAX_SIZE * 2 = 4,194,304 bytes (4 MB), which is well under the 10 MB hardcoded cap. Increasing the payload to Codec.DEFAULT_MAX_SIZE * 10 (20 MB) would trigger the BufferOverflowException.

Affected Files

• pbj-core/pbj-grpc-client-helidon/src/main/java/com/hedera/pbj/grpc/client/helidon/PbjGrpcDatagramReader.java:40 — Hardcoded MAX_BUFFER_SIZE = 10 * 1024 * 1024
• pbj-core/pbj-grpc-client-helidon/src/main/java/com/hedera/pbj/grpc/client/helidon/PbjGrpcDatagramReader.java:164 — ensureCapacity throws BufferOverflowException at hardcoded limit
• pbj-core/pbj-grpc-client-helidon/src/main/java/com/hedera/pbj/grpc/client/helidon/PbjGrpcCall.java:177 — No-arg constructor new PbjGrpcDatagramReader() ignores config maxSize
• pbj-core/pbj-grpc-client-helidon/src/main/java/com/hedera/pbj/grpc/client/helidon/PbjGrpcClientConfig.java:40 — maxSize field accepted but not propagated to datagram reader

Notes

• The PbjGrpcDatagramReader class has no constructor that accepts a max buffer size — only the no-arg constructor exists
• The comment on line 37-38 of PbjGrpcDatagramReader.java acknowledges: "These are arbitrary limits, but they seem sane... It would be nice to make them configurable in the future"
• The fix requires: (1) adding a constructor to PbjGrpcDatagramReader accepting maxBufferSize, (2) using it in ensureCapacity instead of the constant, and (3) passing config.maxSize() from PbjGrpcCall.receiveRepliesLoop

---

Proceeding to Step 6: Root Cause Analysis

[Serhan-Asad]

Step 6: Root Cause Analysis

Root Cause Identified: Yes

Summary

The bug is an incomplete configuration propagation: PR #753 (merged 2026-03-13) added the maxSize parameter to PbjGrpcClientConfig and correctly wired it to Codec.parse() for message deserialization, but failed to propagate it to PbjGrpcDatagramReader, which accumulates raw HTTP/2 DATA frames into complete gRPC datagrams. The reader enforces a hardcoded MAX_BUFFER_SIZE of 10 MB (10 * 1024 * 1024), so any gRPC response whose raw frame data exceeds 10 MB throws BufferOverflowException in ensureCapacity(), regardless of the maxSize configured by the caller.

Technical Details

• Location 1 (symptom): PbjGrpcDatagramReader.java:40 — hardcoded constant

private static final int MAX_BUFFER_SIZE = 10 * 1024 * 1024;

• Location 2 (root cause): PbjGrpcCall.java:177 — no-arg constructor ignores config

final PbjGrpcDatagramReader datagramReader = new PbjGrpcDatagramReader();

• Location 3 (config field exists but unused for this purpose): PbjGrpcClientConfig.maxSize — only passed to Codec.parse() at line 210 of PbjGrpcCall.java, never to the datagram reader.

• Why it fails: The data flow has two size gates: (1) PbjGrpcDatagramReader.ensureCapacity() enforces MAX_BUFFER_SIZE when buffering raw frames, and (2) Codec.parse() enforces maxSize when deserializing. Gate (1) uses a hardcoded 10 MB limit that cannot be configured, so payloads >10 MB fail before ever reaching gate (2).

External Research

• Search terms: "PbjGrpcDatagramReader BufferOverflowException", "hashgraph pbj maxSize grpc", "Helidon gRPC client buffer size"
• Sources checked: GitHub Issues/PRs (hashgraph/pbj), StackOverflow, Helidon docs, gRPC-Java issues
• Relevant findings: No external reports of this specific issue. The PbjGrpcDatagramReader is a PBJ-internal class (not from Helidon or gRPC-Java). The source code itself contains a comment acknowledging the gap: "These are arbitrary limits, but they seem sane... It would be nice to make them configurable in the future." (line 37-38)

Repository History

• Relevant commits:
  • PR feat: introduce PbjGrpcClient #519 (merged 2025-06-13): Introduced PbjGrpcClient and PbjGrpcDatagramReader with the hardcoded 10 MB MAX_BUFFER_SIZE
  • PR feat: Codec.parse(..., int maxSize) #639 (merged 2025-10-03): Made maxSize configurable at Codec.parse() level (issue Make maxSize configurable #637)
  • PR feat: support maxSize in PbjGrpcClient #753 (merged 2026-03-13): Added maxSize to PbjGrpcClientConfig — wired it to codec parsing but missed the datagram reader
• Related PRs:
  • PR feat: allow custom maxSize for requests in GRPC server #667 (merged 2025-10-29): Added custom maxSize for gRPC server — shows the server-side pattern exists
  • PR fix: forward maxSize when parsing nested messages #700 (merged 2025-12-01): Forwarded maxSize to nested message parsing — another incomplete propagation fix
  • PR fix: propagate maxSize to PbjGrpcDatagramReader #757 (OPEN): Fix PR by anthony-swirldslabs that addresses this exact issue
• Similar past issues:
  • Issue Make maxSize configurable #637: Made maxSize configurable — the original feature that PBJ Bug: PbjGrpcClientConfig.maxSize Not Respected by PbjGrpcDatagramReader #756 is an incomplete extension of
  • Issue GRPC: support custom maxSize #748: "GRPC: support custom maxSize" — the immediate predecessor that led to PR feat: support maxSize in PbjGrpcClient #753

Experiments Performed

1. Static code trace through PbjGrpcCall.receiveRepliesLoop(): Confirmed the PbjGrpcDatagramReader is constructed with no-arg constructor at line 177. The grpcClient.getConfig().maxSize() is only used at line 210 in replyCodec.parse(). The datagram reader's ensureCapacity() at line 164 checks newLength > MAX_BUFFER_SIZE (hardcoded 10 MB).
2. Reviewed PR fix: propagate maxSize to PbjGrpcDatagramReader #757 diff: The fix introduces a new maxIncomingBufferSize parameter (separate from maxSize) to PbjGrpcClientConfig, adds a constructor PbjGrpcDatagramReader(int maxBufferSize) that replaces the static constant with an instance field, and passes the config value at the construction site. This confirms the root cause and validates the fix approach.
3. Verified existing test inadequacy: testUnaryMethodReceivingExtraLargePayload uses Codec.DEFAULT_MAX_SIZE * 2 = 4 MB payload, which is well under the 10 MB cap, so it never exercises the buffer limit.

Fix Scope

• Type: Localized
• The fix touches 2 files in the main source (+ test/integration updates):
  1. PbjGrpcDatagramReader.java — replace static MAX_BUFFER_SIZE with instance field, add constructor
  2. PbjGrpcCall.java — pass config value to the new constructor
  3. PbjGrpcClientConfig.java — add maxIncomingBufferSize field (PR fix: propagate maxSize to PbjGrpcDatagramReader #757 adds this as a separate parameter from maxSize, defaulting to Codec.DEFAULT_MAX_SIZE * 5)
• This is NOT cross-cutting: the PbjGrpcDatagramReader is only constructed in one place (PbjGrpcCall.receiveRepliesLoop()).

Fix Location

• File(s) to modify:
  1. pbj-core/pbj-grpc-client-helidon/src/main/java/com/hedera/pbj/grpc/client/helidon/PbjGrpcDatagramReader.java
  2. pbj-core/pbj-grpc-client-helidon/src/main/java/com/hedera/pbj/grpc/client/helidon/PbjGrpcCall.java
  3. pbj-core/pbj-grpc-client-helidon/src/main/java/com/hedera/pbj/grpc/client/helidon/PbjGrpcClientConfig.java
• Why this location: The root cause is the missing propagation from config → reader constructor. The symptom appears in PbjGrpcDatagramReader.ensureCapacity(), but the TRUE root cause is in PbjGrpcCall which fails to pass the configured limit, and in PbjGrpcClientConfig which lacks a dedicated buffer-size field.
• Existing pattern: maxSize is already successfully propagated from PbjGrpcClientConfig → Codec.parse() at PbjGrpcCall.java:210. The fix extends this same pattern to also propagate a buffer size to PbjGrpcDatagramReader.
• Fix approach (matching PR fix: propagate maxSize to PbjGrpcDatagramReader #757):
  1. Add maxIncomingBufferSize field to PbjGrpcClientConfig (distinct from maxSize because the buffer must be larger than maxSize to account for protobuf metadata and streaming)
  2. Add PbjGrpcDatagramReader(int maxBufferSize) constructor, replace MAX_BUFFER_SIZE constant with instance field
  3. In PbjGrpcCall.receiveRepliesLoop(), construct new PbjGrpcDatagramReader(grpcClient.getConfig().maxIncomingBufferSize())

---

Proceeding to Step 7: Prompt Classification

[Serhan-Asad]

Step 7: Prompt Classification

Classification: Code Bug

DEFECT_TYPE: code

Analysis

This is a straightforward code bug — an incomplete implementation where a configuration value (maxSize) is accepted but never propagated to the component that enforces the size limit. No prompt files exist in this repository (it is not PDD-managed), so a prompt defect is not applicable. Even analyzing it purely on specification vs. implementation grounds, the intent is clear: PbjGrpcClientConfig.maxSize exists specifically to control the maximum receivable message size, but the code fails to wire it through.

Evidence

• Specification (API contract): PbjGrpcClientConfig accepts a maxSize parameter documented as controlling the maximum message size for gRPC responses
• Code implements: PbjGrpcCall.receiveRepliesLoop() constructs PbjGrpcDatagramReader with a no-arg constructor (line 177), ignoring the configured maxSize. The reader enforces a hardcoded MAX_BUFFER_SIZE = 10_485_760 (10 MB)
• User expects: Configuring maxSize = 37_748_736 (36 MB) should allow receiving responses up to 36 MB — this matches the documented API contract

Conclusion

The code does not correctly implement its own API contract. The maxSize configuration parameter is accepted but never used by the datagram reader that enforces the buffer size limit. This is a configuration propagation gap, not a specification defect. Proceeding with test generation.

---

Proceeding to Step 8: Test Plan

[Serhan-Asad]

Step 8: Test Plan

Existing Test Coverage

• Test file: Test class containing testUnaryMethodReceivingExtraLargePayload (likely in pbj-grpc-helidon/src/test/java/)
• Current coverage: Tests large payload reception at Codec.DEFAULT_MAX_SIZE * 2 (4 MB) with a custom maxSize config. This passes because 4 MB is well under the hardcoded 10 MB MAX_BUFFER_SIZE.
• Gap: No test exercises a payload above the 10 MB hardcoded limit in PbjGrpcDatagramReader.ensureCapacity. The existing test only validates that codec-level maxSize works, not that the buffer-level limit respects the configured value.

Affected Channels

This is a configuration propagation bug that manifests through three channels:

1. Exception channel — BufferOverflowException thrown from PbjGrpcDatagramReader.ensureCapacity when buffer exceeds hardcoded 10 MB, regardless of configured maxSize
2. Constructor/wiring channel — PbjGrpcCall.receiveRepliesLoop() constructs PbjGrpcDatagramReader with no-arg constructor; maxSize is never passed
3. Unit-level channel — PbjGrpcDatagramReader itself has no way to accept a custom buffer limit (no parameterized constructor)

Proposed Tests

Test 1: testUnaryMethodReceivingPayloadExceeding10MBWithConfiguredMaxSize (Primary — reproduces exact bug)

• Input: Create a gRPC server returning a response of Codec.DEFAULT_MAX_SIZE * 10 (~20 MB). Create client with maxSize = Codec.DEFAULT_MAX_SIZE * 10 via GrpcTestUtils.createGrpcClient().
• Expected: The call succeeds; the response is fully received and parsed without exception.
• Actual (before fix): java.nio.BufferOverflowException in PbjGrpcDatagramReader.ensureCapacity because the buffer hits the hardcoded 10 MB cap.
• Channel: Exception channel — verifies no BufferOverflowException is thrown for payloads within the configured limit but above 10 MB.

Test 2: testDatagramReaderRespectsConfiguredMaxBufferSize (Unit — validates reader accepts custom limit)

• Input: Construct PbjGrpcDatagramReader with a custom maxBufferSize parameter (e.g., 20 MB). Feed it data frames totalling 15 MB.
• Expected: Buffer accumulates data without exception (15 MB < 20 MB configured limit).
• Actual (before fix): Cannot test — no parameterized constructor exists. After fix, this validates the new constructor works.
• Channel: Constructor/wiring channel — verifies the reader can accept and respect a custom buffer limit.

Test 3: testDatagramReaderThrowsWhenExceedingConfiguredMaxBufferSize (Unit — validates enforcement)

• Input: Construct PbjGrpcDatagramReader with maxBufferSize = 5_000_000 (5 MB). Feed it data frames totalling 6 MB.
• Expected: BufferOverflowException is thrown when buffer exceeds the configured 5 MB limit.
• Channel: Exception channel — verifies the configurable limit is actually enforced (not just accepted and ignored).

Test 4: testDatagramReaderDefaultMaxBufferSizePreserved (Regression — backward compatibility)

• Input: Construct PbjGrpcDatagramReader with the no-arg constructor (default behavior). Feed it data frames totalling 8 MB (under default 10 MB).
• Expected: No exception — existing behavior preserved. The default 10 MB limit still applies when no custom limit is configured.
• Channel: Constructor/wiring channel — ensures the fix doesn't break existing clients that don't specify maxSize.

Test 5: testDatagramReaderDefaultConstructorStillEnforcesLimit (Regression — default limit enforcement)

• Input: Construct PbjGrpcDatagramReader with the no-arg constructor. Feed it data frames totalling 11 MB (over default 10 MB).
• Expected: BufferOverflowException is thrown at the default 10 MB limit.
• Channel: Exception channel — ensures default limit is still enforced for backward compatibility.

Test 6: testMaxSizePropagatedFromConfigToDatagramReader (Integration — wiring verification)

• Input: Create PbjGrpcClientConfig with maxSize = 37_748_736 (36 MB). Verify that when PbjGrpcCall.receiveRepliesLoop() constructs the datagram reader, it passes this value through.
• Expected: The PbjGrpcDatagramReader instance uses 36 MB as its buffer limit, not the hardcoded 10 MB.
• Channel: Configuration propagation — verifies the full config → call → reader wiring.

Test Location

• File: Same test class that contains testUnaryMethodReceivingExtraLargePayload (for Tests 1, 6 — end-to-end gRPC tests)
• File: New or existing unit test class for PbjGrpcDatagramReader (for Tests 2-5 — isolated unit tests)
• Framework: JUnit 5 (project standard)

Coverage Check Against Issue Symptoms

Symptom from Issue	Test Covering It
BufferOverflowException for payloads > 10 MB despite configured maxSize	Test 1 (primary reproduction)
PbjGrpcDatagramReader uses hardcoded MAX_BUFFER_SIZE that can't be overridden	Tests 2, 3 (unit-level configurable limit)
maxSize field on PbjGrpcClientConfig never read by reader	Test 6 (wiring verification)
Existing test passes only because payload < 10 MB	Test 1 (same pattern, larger payload)

Cross-Step Consistency Check

• Steps 4-5 confirmed no external API dependencies — all tests can run in-process with a local gRPC server (same pattern as existing testUnaryMethodReceivingExtraLargePayload).
• Step 6 identified 3 files — tests cover all three: PbjGrpcDatagramReader (Tests 2-5), PbjGrpcCall (Test 6), PbjGrpcClientConfig (Test 6).
• No mocking contradictions — Tests 1/6 use the same real local gRPC server setup as existing tests. Tests 2-5 are direct unit tests requiring no mocks.

Notes

• Test 1 payload size (20 MB) should be large enough to exceed the 10 MB hardcoded limit but small enough to run in CI without memory issues.
• Tests 2-5 can use smaller sizes for speed — the key is testing relative to the configured limit, not absolute size.
• The existing GrpcTestUtils.createGrpcClient() already accepts a maxSize parameter, so Test 1 follows the established pattern exactly.
• PR fix: propagate maxSize to PbjGrpcDatagramReader #757 (already open) implements the fix — these tests should validate that PR's changes.

---

Proceeding to Step 9: Generate Test