You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Martijn Visser (Jira)" <ji...@apache.org> on 2026/07/03 20:05:00 UTC

[jira] [Created] (FLINK-40069) OpenTelemetryMetricReporterProtocolTest fails with "No content to map due to end-of-input" due to OTel collector readiness race

Martijn Visser created FLINK-40069:
--------------------------------------

             Summary: OpenTelemetryMetricReporterProtocolTest fails with "No content to map due to end-of-input" due to OTel collector readiness race
                 Key: FLINK-40069
                 URL: https://issues.apache.org/jira/browse/FLINK-40069
             Project: Flink
          Issue Type: Bug
          Components: Runtime / Metrics, Tests
    Affects Versions: 2.4.0
            Reporter: Martijn Visser
            Assignee: Martijn Visser


https://dev.azure.com/apache-flink/apache-flink/_build/results?buildId=76609&view=results (leg: test_cron_jdk21_connect)

{{testGzipCompressionGrpc}} and {{testGzipCompressionHttp}} each failed after exhausting the full 2-minute {{eventually()}} budget:

{noformat}
org.apache.flink.shaded.jackson2.com.fasterxml.jackson.databind.exc.MismatchedInputException: No content to map due to end-of-input
      at org.apache.flink.metrics.otel.OpenTelemetryTestBase.lambda$eventuallyConsumeJson$1(OpenTelemetryTestBase.java:114)
      at org.apache.flink.metrics.otel.OpenTelemetryMetricReporterProtocolTest.assertReported(OpenTelemetryMetricReporterProtocolTest.java:66)
      at org.apache.flink.metrics.otel.AbstractOpenTelemetryReporterProtocolTest.testGzipCompressionGrpc(AbstractOpenTelemetryReporterProtocolTest.java:88)
{noformat}

Root cause: {{OtelTestContainer}} sets no wait strategy, so testcontainers uses the default {{HostPortWaitStrategy}}. The shell-less {{otel/opentelemetry-collector}} image cannot run the internal exec check ("/bin/sh: no such file or directory"), leaving only the external host-port probe, which reports the mapped port ready before the OTLP receiver accepts connections. The test's single one-shot {{report()}} was invoked before the collector logged readiness, so the export failed ({{Metric export completed with issues: ... successfulBatches=0, failedBatches=1}}) and, because the assertion loop only re-reads the collector output file and never re-exports, the file stayed empty for the whole timeout. Gzip is incidental: those two tests simply ran first against the cold container.

Proposed fix: (1) wait for the collector's "Everything is ready. Begin running and processing data." log line (emitted only after all components including the OTLP receivers started) with a bounded startup timeout; (2) re-invoke {{report()}} inside the retry loop so a single failed export (including a transient HTTP 404) cannot doom the whole budget.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)