apache/iceberg · error · IllegalArgumentException

Invalid operator event type:

Error message

Invalid operator event type: 

What it means

DataStatisticsCoordinator.handleEventFromOperator dispatches operator events from subtasks; only StatisticsEvent and RequestGlobalStatisticsEvent are recognized. Any other OperatorEvent type is rejected with IllegalArgumentException naming the event's canonical class name.

Source

Thrown at flink/v2.2/flink/src/main/java/org/apache/iceberg/flink/sink/shuffle/DataStatisticsCoordinator.java:322

    }
  }

  @Override
  public void handleEventFromOperator(int subtask, int attemptNumber, OperatorEvent event) {
    runInCoordinatorThread(
        () -> {
          LOG.debug(
              "Handling event from subtask {} (#{}) of {}: {}",
              subtask,
              attemptNumber,
              operatorName,
              event);
          if (event instanceof StatisticsEvent) {
            handleDataStatisticRequest(subtask, ((StatisticsEvent) event));
          } else if (event instanceof RequestGlobalStatisticsEvent) {
            handleRequestGlobalStatisticsEvent(subtask, (RequestGlobalStatisticsEvent) event);
          } else {
            throw new IllegalArgumentException(
                "Invalid operator event type: " + event.getClass().getCanonicalName());
          }
        },
        String.format(
            Locale.ROOT,
            "handling operator event %s from subtask %d (#%d)",
            event.getClass(),
            subtask,
            attemptNumber));
  }

  @Override
  public void checkpointCoordinator(long checkpointId, CompletableFuture<byte[]> resultFuture) {
    runInCoordinatorThread(
        () -> {
          LOG.debug(
              "Snapshotting data statistics coordinator {} for checkpoint {}",
              operatorName,

View on GitHub (pinned to 86d9c8fc54)

Solutions

  1. Ensure all TaskManagers and the JobManager run the same iceberg-flink version so only known event types are sent.
  2. Check custom code for OperatorEvents being sent to DataStatisticsCoordinator that it does not handle.
  3. Restart the cluster fully (not rolling) after an upgrade to eliminate mixed-version events.
Defensive patterns

Strategy: try-catch

Validate before calling

if (!(event instanceof StatisticsEvent) && !(event instanceof RequestGlobalStatisticsEvent)) { throw new IllegalArgumentException("Event not handled by DataStatisticsCoordinator: " + event.getClass().getName()); }

Try / catch

try { coordinator.handleEventFromOperator(subtask, event); } catch (IllegalArgumentException e) { /* log the unknown event class and check for version skew */ }

Prevention

When it happens

Trigger: An OperatorEvent arriving at the coordinator that is neither StatisticsEvent nor RequestGlobalStatisticsEvent — e.g. mismatched jar versions where a subtask sends an event class the coordinator doesn't know, or a custom event wired into this coordinator.

Common situations: Mixed iceberg-flink jar versions between JobManager/TaskManager during rolling upgrades; custom operator event subclasses routed to the wrong coordinator.

Related errors


AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12). Data as JSON: /api/errors/3c4a741f74052ac9. Report an issue: GitHub.