apache/seatunnel · warning
Some vertices may not be reporting metrics yet for table
Error message
Some vertices may not be reporting metrics yet for table '{}': expected {} vertices {}, but only received metrics for {} vertices {} What it means
While aggregating per-table metrics, processMetric() compares the number of vertices that actually reported metrics (metricsByIdentifier) against the number of configured vertices (vertexIdentifiers). When fewer vertices reported than expected for a multi-vertex table, it logs this warning listing expected and received vertices — some parallel subtasks/vertices haven't published their metrics yet.
Solutions
- Wait and re-poll metrics once all vertices are running; this is often a startup timing issue.
- Check the job's vertex/task status for failed or stuck subtasks.
- Verify parallelism settings and that all subtasks registered with the metrics system.
- If a vertex never reports, inspect task logs for initialization errors.
Defensive patterns
Strategy: retry
Validate before calling
// wait until all vertices report before consuming table metrics
if (metricsByIdentifier.size() < vertexIdentifiers.size()) {
// defer aggregation or re-poll after a delay
} Try / catch
try {
Map<String, Object> m = getJobMetrics(jobId);
} catch (IncompleteMetricsException e) {
// retry with backoff until all vertices report
} Prevention
- Delay metrics consumption until the job reaches RUNNING state with all subtasks started
- Alert on vertices that never report metrics (task failure indicator)
- Check subtask logs when expected vertex count is not met
When it happens
Trigger: Polling job metrics while some vertices (source/sink parallel instances) have not yet started or reported; vertex identifiers configured for a table exceed the identifiers present in the raw metrics payload.
Common situations: Querying metrics immediately after job submission before all subtasks initialize; a stalled or failed subtask not reporting; transient latency between task start and first metric flush.
Understand the failure class
Background: EmptyResultError / "no results found": when an API or scraper succeeds but returns zero rows — this error's family across 9 libraries.
Related errors
- Cannot reliably determine vertex assignment for table
- Failed to load finished job metrics for job
- Found unassigned metric entries for table ' ' metric ' '…
- Metric array size mismatch for table
- Metric array size mismatch for table
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/0797a30387012788.
Report an issue: GitHub.
Appendix: source
Thrown at seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/rest/service/BaseService.java:869
unassignedMetrics.add(node);
}
}
if (!metricsByIdentifier.isEmpty()) {
metricsByIdentifier.keySet().stream()
.sorted(vertexIdentifierComparator())
.forEach(
identifier -> {
putMetricToMap(
metricName,
identifier + "." + tableName,
metricsByIdentifier.get(identifier),
tableMetricsMaps);
});
if (vertexIdentifiers.size() > 1
&& metricsByIdentifier.size() < vertexIdentifiers.size()) {
log.warn(
"Some vertices may not be reporting metrics yet for table '{}': expected {} vertices {}, but only received metrics for {} vertices {}",
tableName,
vertexIdentifiers.size(),
vertexIdentifiers,
metricsByIdentifier.size(),
metricsByIdentifier.keySet());
}
if (unassignedMetrics != null && unassignedMetrics.size() > 0) {
log.warn(
"Found {} unassigned metric entries for table '{}' metric '{}', using table name key only for these entries",
unassignedMetrics.size(),
tableName,
metricName);
putMetricToMap(metricName, tableName, unassignedMetrics, tableMetricsMaps);
}
return;
}View on GitHub (pinned to cf67b549a7)