Enforce OTLP request size limits by ADITYA-CODE-SOURCE · Pull Request #8446 · open-telemetry/opentelemetry-java

ADITYA-CODE-SOURCE · 2026-06-03T03:28:08Z

Why

opentelemetry-proto#782 now recommends that OTLP exporters enforce configurable outbound request/message size limits.
OpenTelemetry Java already limits response body reads, but OTLP exporters did not enforce outbound request/message limits.

What

add configurable request/message size limits to OTLP HTTP and gRPC exporter builders with a default of 64 MiB
enforce the limit in the shared OTLP HTTP and gRPC exporter layers before dispatching requests
cover both known-size binary payloads and unknown-size payloads (for example OTLP HTTP JSON) by measuring when needed
add focused tests for over-limit failure behavior and builder configuration plumbing
update docs/apidiffs/current_vs_latest/opentelemetry-exporter-otlp.txt for the new public builder methods

Testing

I was not able to complete local Gradle verification on this Windows machine because Gradle / the Kotlin compiler daemon repeatedly failed to start due to paging-file / metaspace limits before compilation finished. The changes are pushed for CI verification.

otelbot · 2026-06-03T03:28:18Z

⚠️ API changes detected — additional maintainer review required

@jack-berg @jkwatson

This PR modifies the public API surface area of the following module(s):

opentelemetry-exporter-otlp

Please review the changes in docs/apidiffs/current_vs_latest/ carefully before approving.

ADITYA-CODE-SOURCE · 2026-06-04T08:32:58Z

@jkwatson Thanks — I pushed a follow-up that fixes the NullAway compile failure in the OTLP internal exporters and applies the naming nits to use constants and public API parameter names.

jack-berg

A few small comments, but looks pretty good! Thanks for working on this!

jack-berg · 2026-06-10T17:41:00Z

  private final boolean exportAsJson;
+  private final long maxRequestBodySize;

  public HttpExporter(


This is internal code so we can change the constructor without worrying about breaking any callers. Let's have a single constructor.

jack-berg · 2026-06-10T17:41:35Z

 public final class HttpExporterBuilder {
  public static final long DEFAULT_TIMEOUT_SECS = 10;
  public static final long DEFAULT_CONNECT_TIMEOUT_SECS = 10;
+  public static final long DEFAULT_MAX_REQUEST_BODY_SIZE = Long.MAX_VALUE;


Can we default to 64mb here? Allows the constant to be defined in once place rather than in each of the exporter builders.

jack-berg · 2026-06-10T17:42:47Z

+  public OtlpGrpcLogRecordExporterBuilder setMaxRequestMessageSize(
+      long maxRequestMessageSizeBytes) {
+    checkArgument(
+        maxRequestMessageSizeBytes >= 0, "maxRequestMessageSizeBytes must be non-negative");


Setting the max body size to 0 is not useful. (Update applies in other places as well)

Suggested change

maxRequestMessageSizeBytes >= 0, "maxRequestMessageSizeBytes must be non-negative");

maxRequestMessageSizeBytes > 0, "maxRequestMessageSizeBytes must be positive");

jack-berg · 2026-06-10T17:46:10Z

+    int contentLength = messageWriter.getContentLength();
+    if (contentLength >= 0) {
+      return contentLength;
+    }


Under what conditions do we pass through this?

My read of the code shows that only Marshaler.toJsonMessageWriter produces a MessageWriter.getContentLength which can return a value <= 0.

I don't know that we can cheaply compute the / enforce the body size for OTLP/json. One more reason not to use it. Officially, we don't support it today. See #5833

jack-berg · 2026-06-10T17:47:55Z

@@ -65,15 +86,70 @@ public CompletableResultCode export(Marshaler exportRequest, int numItems) {
        exporterMetrics.startRecordingExport(numItems);

    CompletableResultCode result = new CompletableResultCode();


Since failRequestTooLarge produces its own CompletableResultCode, let's initialize this after line 94.

jack-berg · 2026-06-10T17:50:40Z

+      ExporterInstrumentation.Recording metricRecording,
+      long requestMessageSize) {
+    String errorMessage =
+        "OTLP gRPC request message size "


Let's keep the log message consistent with the shape we use elsewhere in this class when exports fail:

"Failed to export " + type + "s. Request message size " + requestMessageSize + "exceeded limit of " + maxRequestMessageSize + "bytes".

Same advice applies to HttpExporter.

jack-berg · 2026-06-10T17:52:19Z

+    throw new UnsupportedOperationException("Not implemented");
+  }
+
+  default TelemetryExporterBuilder<T> setMaxRequestMessageSize(long maxRequestMessageSize) {


No default needed here. This is an internal interface so better to fail loudly with a compile error if an implementation forgot to implement.

jack-berg · 2026-06-10T17:52:34Z

+          exporter.export(Collections.singletonList(generateFakeTelemetry()));
+
+      assertThat(result.join(10, TimeUnit.SECONDS).isSuccess()).isFalse();
+      Assertions.assertThat(result.getFailureThrowable())


#nit:

Suggested change

Assertions.assertThat(result.getFailureThrowable())

assertThat(result.getFailureThrowable())

jack-berg · 2026-06-10T17:53:11Z

+      Assertions.assertThat(result.getFailureThrowable())
+          .hasMessageContaining("OTLP gRPC request message size")
+          .hasMessageContaining("exceeded limit of 1 bytes");
+    }


I think there are test methods in these that verify toString. Should update to assert that the new limit field is included in toString.

ADITYA-CODE-SOURCE requested a review from a team as a code owner June 3, 2026 03:28

otelbot Bot added the api-change Changes to public API surface area label Jun 3, 2026

ADITYA-CODE-SOURCE force-pushed the issue-8444-otlp-message-limits branch from 280870d to 6720aae Compare June 3, 2026 03:30

github-actions Bot mentioned this pull request Jun 3, 2026

Pull Request Dashboard #8439

Open

jkwatson reviewed Jun 3, 2026

View reviewed changes

Comment thread ...all/src/main/java/io/opentelemetry/exporter/otlp/http/trace/OtlpHttpSpanExporterBuilder.java Outdated

jkwatson reviewed Jun 3, 2026

View reviewed changes

Comment thread ...src/main/java/io/opentelemetry/exporter/otlp/http/logs/OtlpHttpLogRecordExporterBuilder.java Outdated

jack-berg reviewed Jun 10, 2026

View reviewed changes

ADITYA-CODE-SOURCE added 5 commits June 11, 2026 09:04

Enforce OTLP request size limits

8445c89

Fix OTLP request limit CI issues

be464f3

Apply spotless fixes for OTLP request limits

818c4f2

Fix OTLP exporter test imports

3a63d22

Address OTLP request limit review feedback

3cf2f56

ADITYA-CODE-SOURCE force-pushed the issue-8444-otlp-message-limits branch from afad5b0 to 3cf2f56 Compare June 11, 2026 04:49

	maxRequestMessageSizeBytes >= 0, "maxRequestMessageSizeBytes must be non-negative");
	maxRequestMessageSizeBytes > 0, "maxRequestMessageSizeBytes must be positive");

		@@ -65,15 +86,70 @@ public CompletableResultCode export(Marshaler exportRequest, int numItems) {
		exporterMetrics.startRecordingExport(numItems);

		CompletableResultCode result = new CompletableResultCode();

	Assertions.assertThat(result.getFailureThrowable())
	assertThat(result.getFailureThrowable())

Conversation

ADITYA-CODE-SOURCE commented Jun 3, 2026

Why

What

Testing

Uh oh!

otelbot Bot commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

⚠️ API changes detected — additional maintainer review required

Uh oh!

Uh oh!

Uh oh!

ADITYA-CODE-SOURCE commented Jun 4, 2026

Uh oh!

jack-berg left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

otelbot Bot commented Jun 3, 2026 •

edited

Loading