apache/beam · error · RuntimeException

getMonitoringInfos is not implemented on this MetricsContain

Error message

getMonitoringInfos is not implemented on this MetricsContainer.

What it means

MetricsContainer is an interface where getMonitoringInfos is a default method that throws RuntimeException. Containers that do not override it (no-op or partially implemented containers) throw this error when someone asks for their cumulative MonitoringInfo values.

Source

Thrown at sdks/java/core/src/main/java/org/apache/beam/sdk/metrics/MetricsContainer.java:77

  StringSet getStringSet(MetricName metricName);

  /**
   * Return the {@link BoundedTrie} that should be used for implementing the given {@code
   * metricName} in this container.
   */
  BoundedTrie getBoundedTrie(MetricName metricName);

  /**
   * Return the {@link Histogram} that should be used for implementing the given {@code metricName}
   * in this container.
   */
  default Histogram getHistogram(MetricName metricName, HistogramData.BucketType bucketType) {
    return NoOpHistogram.getInstance();
  }

  /** Return the cumulative values for any metrics in this container as MonitoringInfos. */
  default Iterable<MetricsApi.MonitoringInfo> getMonitoringInfos() {
    throw new RuntimeException("getMonitoringInfos is not implemented on this MetricsContainer.");
  }
}

View on GitHub (pinned to 12126d8942)

Solutions

Override getMonitoringInfos() in the MetricsContainer implementation to return the accumulated MonitoringInfo values.
If the container is intentionally a no-op, return an empty iterable instead of relying on the throwing default.
Use a fully supported container implementation (e.g. from runners-core) that implements the export.
Wrap the call and fall back to per-metric getters when export is unsupported.

Example fix

// before
container.getMonitoringInfos(); // throws
// after
List<MonitoringInfo> infos = container instanceof MyContainer
    ? ((MyContainer) container).getMonitoringInfos()
    : Collections.emptyList();

Defensive patterns

Strategy: try-catch

Validate before calling

boolean supportsExport = container.getClass().getMethod("getMonitoringInfos").getDeclaringClass() != MetricsContainer.class;

Try / catch

try { infos = container.getMonitoringInfos(); } catch (RuntimeException e) { infos = Collections.emptyList(); }

Prevention

Implement getMonitoringInfos() in all custom MetricsContainer classes
Never rely on throwing default interface methods in stubs
Return empty iterables from no-op containers instead of throwing

When it happens

Trigger: Calling getMonitoringInfos() on a MetricsContainer implementation that only implements the metric-getter methods but not getMonitoringInfos — e.g. a custom container or a test stub.

Common situations: Custom runner integrations that extract metrics from their own containers, unit tests stubbing MetricsContainer, or harness code pulling MonitoringInfos from containers that never supported export.

Related errors

AI-assisted analysis of apache/beam@12126d8942 (2026-09-13). Data as JSON: /api/errors/e9e555c455cdece3. Report an issue: GitHub.