Treat declarative config max_request_size of 0 as no limit in OTLP exporters

[thswlsqls]

Fixes #8940

Description

• The declarative config schema (v1.2.0) says for max_request_size: "A value of 0 indicates no limit (infinity) and is not recommended."
• OtlpDeclarativeConfigUtil passed 0 to setMaxRequestBodySize / setMaxRequestMessageSize, which only accept positive values, so SDK creation failed with DeclarativeConfigException.
• 0 is now mapped to Long.MAX_VALUE, as timeout: 0 already is. The limit is only used in size > max checks, so this turns the check off.
• Public builders are unchanged; negative values are still rejected.
• Context: the option was added in Enforce OTLP request size limits #8446; the meaning of 0 was agreed in feat: add OTLP request and response size limits opentelemetry-configuration#700.

Testing done

• Added otlp_http max_request_size 0 and otlp_grpc max_request_size 0 cases to SpanExporterFactoryTest, MetricExporterFactoryTest and LogRecordExporterFactoryTest.
• With the fix reverted, all 6 new cases fail with DeclarativeConfigException (... must be positive). With the fix, all 41 tests in these classes pass.
• ./gradlew :exporters:otlp:all:check :sdk-extensions:declarative-config:check passed (1190 and 546 tests). No apidiff change (internal package).

[opentelemetry-pr-dashboard]

Pull request dashboard status

Waiting on the author · refreshed 2026-10-14 05:33 UTC

Respond to 1 review item (e.g. link a commit, explain why not, ask a follow-up):

• Top-level threads: 1

Status above doesn't look right?

• Just replied or pushed? Anything around or after the refresh time above may not be picked up yet — give it a few minutes.
• Should this be with reviewers? Comment /dashboard route:reviewers to route it to them.
• Anything wrong — including the routing? Report it with what you expected; it helps us improve the dashboard.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.66%. Comparing base (387f5c5) to head (bcf55df).

Additional details and impacted files

@@            Coverage Diff            @@
##               main    #8945   +/-   ##
=========================================
  Coverage     90.65%   90.66%           
- Complexity    10887    10889    +2     
=========================================
  Files          1015     1015           
  Lines         29731    29731           
  Branches       3876     3877    +1     
=========================================
+ Hits          26953    26955    +2     
  Misses         1860     1860           
+ Partials        918      916    -2     

☔ View full report in Codecov by Harness.
📢 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.

[psx95]

Could we instead make this change in the internal exporter builders instead?

For instance, we could make this change in here in HttpExporterBuilder.

The handling of 0 value for timeout is also done here. This would make the behavior of configuring SDK programmatically vs via declarative config consistent.

The config options listed in exporter spec do not explicitly state how to handle 0, but I think the spec might just be outdated.

Perhaps other maintainers would want to chime in here?
cc: @jack-berg , @jkwatson

[thswlsqls]

@psx95 Thanks for the review. Moving it into the internal builders makes sense to me, and it would match how setTimeout treats 0.

One catch: the public setters reject 0 before the internal builder sees it (checkArgument(maxRequestBodySizeBytes > 0, ...) in OtlpHttpSpanExporterBuilder.setMaxRequestBodySize, and the same in the other five OTLP builders). So this would also mean relaxing that check to >= 0 and documenting 0 as "no limit" on the stable builders. That's why I kept the change in the declarative config layer.

I'll wait for @jack-berg / @jkwatson to weigh in and update the PR either way.