Response body bounds

[jack-berg]

Add new max response body size parameter to sender config, defaulting to 4mb.

Per the spec, if a response exceeding the limit is received:

• grpc: fail with RESOURCE_EXHAUSTED code, do not retry
• http: fail with exception, do not retry

For OTLP exporters, the body size is not configurable, since we don't do anything with the response today. If adding this 4mb limit causes new exceptions for users, we can add a config option to allow it to be increased.

For JaegerRemoteSampler, a new programmatic config option is added because the responses are critical to the function of the sampler.

cc @brunobat you'll want to update the vertex sender to incorporate this new option.

[codecov]

Codecov Report

❌ Patch coverage is 80.58252% with 20 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.29%. Comparing base (47c970d) to head (cc98859).

Files with missing lines	Patch %	Lines
...ry/exporter/sender/jdk/internal/JdkHttpSender.java	80.00%	5 Missing and 1 partial ⚠️
...orter/sender/okhttp/internal/OkHttpGrpcSender.java	86.11%	3 Missing and 2 partials ⚠️
...orter/sender/okhttp/internal/OkHttpHttpSender.java	84.00%	2 Missing and 2 partials ⚠️
...ace/jaeger/sampler/JaegerRemoteSamplerBuilder.java	25.00%	3 Missing ⚠️
...ntelemetry/sdk/common/export/GrpcSenderConfig.java	0.00%	1 Missing ⚠️
...ntelemetry/sdk/common/export/HttpSenderConfig.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8224      +/-   ##
============================================
- Coverage     90.31%   90.29%   -0.02%     
- Complexity     7652     7662      +10     
============================================
  Files           843      845       +2     
  Lines         23087    23140      +53     
  Branches       2312     2323      +11     
============================================
+ Hits          20851    20895      +44     
- Misses         1517     1521       +4     
- Partials        719      724       +5     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[zeitlinger]

JaegerRemoteSamplerBuilder.setMaxSamplingStrategyResponseBodySize validates bytes > 0. But the sender constructors (JdkHttpSender, OkHttpHttpSender, OkHttpGrpcSender) accept any long without
validation. A caller can bypass the guard by constructing a sender directly with 0 or -1. Consider adding the validation at the sender level too, or document the expected invariant.

[jack-berg]

All the sender constructors are internal, and have a bunch of other unvalidated parameters which could be equally corrupted if a user goes around the guards. There's a conversation here discussing where to add additional null checks beyond the guarantees from nullaway. I think we should adopt a policy of adding additional null checks at the API boundaries, but trusting nullaway once we're within the walled garden of internal code. The same would apply to parameter validation, I think.

[zeitlinger]

GrpcExporterBuilder and HttpExporterBuilder hardcode 4MB with no setter. Only JaegerRemoteSamplerBuilder exposes a public setter. If a user wants to tighten the OTLP limit (say, to 64KB since responses are tiny), they can't. Worth a deliberate decision: intentionally omit setters for OTLP (since responses are well-known small), or add them for consistency?

[jack-berg]

I omitted them in OTLP for now because we don't do anything with them and a 4mb limit is an improvement on the current no limit.

In contrast, for JaegerRemoteSampler, the default body size reduction is a change in behavior which could be meaningful so adding the setter seems essential.