apache/seatunnel · warning

Ignoring attempted add of a metric due to being null for nam

Error message

Ignoring attempted add of a metric due to being null for name {}.

What it means

AbstractMetricsContext.addMetric guards against registering a null Metric instance. A null metric is rejected with a warning and not stored, so the named metric silently disappears from reports. This is a defensive check in the metrics registry: counter(name, ...) or meter(name, ...) was handed a null Metric object.

Source

Thrown at seatunnel-api/src/main/java/org/apache/seatunnel/api/common/metrics/AbstractMetricsContext.java:63

    }

    @Override
    public Meter meter(String name) {
        if (metrics.containsKey(name)) {
            return (Meter) metrics.get(name);
        }
        return this.meter(name, new ThreadSafeQPSMeter(name));
    }

    @Override
    public <M extends Meter> M meter(String name, M meter) {
        this.addMetric(name, meter);
        return meter;
    }

    protected void addMetric(String name, Metric metric) {
        if (metric == null) {
            log.warn("Ignoring attempted add of a metric due to being null for name {}.", name);
        } else {
            synchronized (this) {
                Metric prior = this.metrics.put(name, metric);
                if (prior != null) {
                    this.metrics.put(name, prior);
                    log.warn(
                            "Name collision: MetricsContext already contains a Metric with the name '"
                                    + name
                                    + "'. Metric will not be reported.");
                }
            }
        }
    }

    @Override
    public String toString() {
        return "AbstractMetricsContext{" + "metrics=" + metrics + '}';
    }

View on GitHub (pinned to cf67b549a7)

Solutions

  1. Find where the null Metric is produced and initialize it before registering.
  2. Check that the underlying metric registry/backend is initialized before creating counters/meters.
  3. Guard the factory call: only call addMetric when the metric instance is non-null.
  4. Log at DEBUG which code path returns null and fix the provider.

Example fix

// before
Counter c = registry.counter(name); // may return null
metricsContext.addMetric(name, c);
// after
Counter c = registry.counter(name);
if (c != null) {
    metricsContext.addMetric(name, c);
}
Defensive patterns

Strategy: type-guard

Validate before calling

if (name == null || name.isEmpty()) throw new IllegalArgumentException("metric name required");

Type guard

if (metric == null) { LOG.warn("skipping null metric {}", name); return; } metricsContext.addMetric(name, metric);

Try / catch

// not exception-based; guard inputs before addMetric

Prevention

When it happens

Trigger: Calling addMetric(name, null) directly, or counter()/meter() factory methods that return null (e.g. a null-returning metric registry lookup) and then pass the result to addMetric.

Common situations: Custom metric registries or third-party metric backends (Prometheus/Dropwizard adapters) returning null for unregistered metrics; plugin code constructing metrics lazily and passing an uninitialized reference.

Related errors


AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/57a363d05b4bfb23. Report an issue: GitHub.