apache/beam · error · ValueError

'Unsupported type %s' % monitoring_info_proto.type

Error message

'Unsupported type %s' % monitoring_info_proto.type

What it means

extract_counter_value raises ValueError when the MonitoringInfo proto's type is not recognized as a counter (is_counter returns False). Only SUM_INT64_TYPE counters are supported for extraction, so any other type URL reaching this function is rejected. Callers normally route via extract_metric_result_map_value, which dispatches by type.

Source

Thrown at sdks/python/apache_beam/metrics/monitoring_infos.py:138

SPANNER_PROJECT_ID = (
    common_urns.monitoring_info_labels.SPANNER_PROJECT_ID.label_props.name)
SPANNER_DATABASE_ID = (
    common_urns.monitoring_info_labels.SPANNER_DATABASE_ID.label_props.name)
SPANNER_TABLE_ID = (
    common_urns.monitoring_info_labels.SPANNER_TABLE_ID.label_props.name)
SPANNER_QUERY_NAME = (
    common_urns.monitoring_info_labels.SPANNER_QUERY_NAME.label_props.name)
BIGTABLE_PROJECT_ID_LABEL = (
    common_urns.monitoring_info_labels.BIGTABLE_PROJECT_ID.label_props.name)
INSTANCE_ID_LABEL = (
    common_urns.monitoring_info_labels.INSTANCE_ID.label_props.name)
TABLE_ID_LABEL = common_urns.monitoring_info_labels.TABLE_ID.label_props.name


def extract_counter_value(monitoring_info_proto):
  """Returns the counter value of the monitoring info."""
  if not is_counter(monitoring_info_proto):
    raise ValueError('Unsupported type %s' % monitoring_info_proto.type)

  # Only SUM_INT64_TYPE is currently supported.
  return coders.VarIntCoder().decode(monitoring_info_proto.payload)


def extract_gauge_value(monitoring_info_proto):
  """Returns a tuple containing (timestamp, value)"""
  if not is_gauge(monitoring_info_proto):
    raise ValueError('Unsupported type %s' % monitoring_info_proto.type)

  # Only LATEST_INT64_TYPE is currently supported.
  return _decode_gauge(coders.VarIntCoder(), monitoring_info_proto.payload)


def extract_distribution(monitoring_info_proto):
  """Returns a tuple of (count, sum, min, max).

  Args:

View on GitHub (pinned to 12126d8942)

Solutions

  1. Use extract_metric_result_map_value instead of calling extract_counter_value directly so the correct extractor is chosen by type.
  2. Filter monitoring infos with is_counter() before calling extract_counter_value.
  3. Upgrade apache-beam to a version that recognizes the metric type being emitted by the runner.

Example fix

// before
value = extract_counter_value(mi)  # mi may be a gauge
// after
if is_counter(mi):
    value = extract_counter_value(mi)
else:
    value = extract_metric_result_map_value(mi)
Defensive patterns

Strategy: type-guard

Validate before calling

from apache_beam.metrics.monitoring_infos import is_counter, extract_counter_value
if is_counter(mi):
    value = extract_counter_value(mi)

Type guard

def is_safe_counter(mi):
    return is_counter(mi)

Try / catch

try:
    value = extract_counter_value(mi)
except ValueError as e:
    logger.warning('skipping non-counter monitoring info: %s', e)
    value = None

Prevention

When it happens

Trigger: Calling extract_counter_value on a MonitoringInfo whose type is a gauge, distribution, string-set, histogram, or bounded-trie type (or an unknown URN/type string).

Common situations: Runner-returned metrics with newer or runner-specific types not known to the client SDK version; manually routing monitoring infos to the wrong extractor after inspecting URNs by hand; SDK/runner version skew where the runner emits types this Beam version cannot decode.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors


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