apache/seatunnel · warning
Cannot reliably determine vertex assignment for table
Error message
Cannot reliably determine vertex assignment for table '{}' metric '{}' (isArray=false) with {} configured vertices, using table name only to avoid incorrect attribution What it means
When aggregating per-table job metrics for the REST API, BaseService.processMetric() expects metric values to be attributable to specific pipeline vertices (identified per table). If the metric JSON node is not an array and the number of configured vertex identifiers for the table is not exactly 1, the service cannot safely attribute the value to a vertex, so it logs this warning and falls back to using just the table name as the metric key.
Solutions
- Inspect the raw job metrics for the table to see why a scalar value is returned for a multi-vertex metric.
- Check engine version consistency — metric serialization format must match the REST service expectations.
- Accept the fallback if table-level attribution is sufficient; the warning explicitly says data is still reported under the table name.
- If the table should have exactly one vertex, verify the job DAG/table configuration.
Defensive patterns
Strategy: validation
Validate before calling
// ensure a single-vertex expectation matches the payload shape
JsonNode metricNode = raw.get(metricName);
if (!metricNode.isArray() && vertexIdentifiers.size() != 1) {
// expect table-name-level attribution only
} Prevention
- Poll metrics only after all vertices are initialized
- Keep engine and REST service versions aligned
- Verify table-to-vertex configuration in the job DAG
- Treat scalar metrics on multi-vertex tables as table-level, not vertex-level
When it happens
Trigger: A table's metric response for a given metric name is a single (non-array) JSON node while the table is configured with 0 or >1 vertex identifiers — e.g. multi-vertex tables receiving aggregated single-value metrics.
Common situations: Source/sink with multiple parallelism reported a merged metric value; metrics format produced by an older/newer engine version differs from what the REST aggregator expects; table used in multiple vertices of the DAG.
Related errors
- 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
- Some vertices may not be reporting metrics yet for table
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/18193aec0c54a6b6.
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:827
return;
}
List<String> vertexIdentifiers =
tableToVertexIdentifiersMap == null
? null
: tableToVertexIdentifiersMap.get(tableName);
if (vertexIdentifiers == null || vertexIdentifiers.isEmpty()) {
putMetricToMap(metricName, tableName, metricNode, tableMetricsMaps);
return;
}
if (!metricNode.isArray()) {
String metricKey = tableName;
if (vertexIdentifiers.size() == 1) {
metricKey = vertexIdentifiers.get(0) + "." + tableName;
} else {
log.warn(
"Cannot reliably determine vertex assignment for table '{}' metric '{}' (isArray=false) with {} configured vertices, using table name only to avoid incorrect attribution",
tableName,
metricName,
vertexIdentifiers.size());
}
putMetricToMap(metricName, metricKey, metricNode, tableMetricsMaps);
return;
}
// Prefer tag-based attribution to handle partial/mismatched arrays reliably.
ObjectMapper mapper = new ObjectMapper();
Map<String, ArrayNode> metricsByIdentifier = new HashMap<>();
ArrayNode unassignedMetrics = null;
for (JsonNode node : metricNode) {
String identifier = extractVertexIdentifierFromMetricNode(node);
if (StringUtils.isNotBlank(identifier) && vertexIdentifiers.contains(identifier)) {
metricsByIdentifier
.computeIfAbsent(identifier, k -> mapper.createArrayNode())View on GitHub (pinned to cf67b549a7)