apache/iceberg · error · IllegalArgumentException

Invalid operator event type:

Error message

Invalid operator event type: 

What it means

TriggerManagerCoordinator.handleEventFromOperator() only accepts LockRegisterEvent from its subtasks. Any other OperatorEvent type is an internal protocol violation and is thrown as IllegalArgumentException naming the event class.

Source

Thrown at flink/v2.3/flink/src/main/java/org/apache/iceberg/flink/maintenance/operator/TriggerManagerCoordinator.java:48

  TriggerManagerCoordinator(String operatorName, Context context) {
    super(operatorName, context);
    LOG.info("Created TriggerManagerCoordinator: {}", operatorName);
  }

  @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 LockRegisterEvent) {
            registerLock((LockRegisterEvent) 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));
  }
}

View on GitHub (pinned to 86d9c8fc54)

Solutions

  1. Ensure only TriggerManagerOperator paired with this coordinator is in the job; verify no custom code sends other events to it
  2. Check for version skew: if restoring from a savepoint, use the same Iceberg version for all job vertices
  3. Review operator EventSender/Coordinator setup to confirm the coordinator is registered for the right operator
  4. If adding new event types, extend handleEventFromOperator to handle them explicitly

Example fix

// before
eventGateway.sendToCoordinator(new LockReleaseEvent(lockId)); // to TriggerManagerCoordinator
// after
eventGateway.sendToCoordinator(new LockRegisterEvent(lockFactory, lockId));
Defensive patterns

Strategy: type-guard

Validate before calling

// before sending an event to TriggerManagerCoordinator
if (!(event instanceof LockRegisterEvent)) {
  throw new IllegalArgumentException("TriggerManagerCoordinator only accepts LockRegisterEvent, got " + event.getClass());
}

Type guard

if (event instanceof LockRegisterEvent lockRegister) {
  eventGateway.sendToCoordinator(lockRegister);
} else { /* handle elsewhere */ }

Try / catch

try {
  coordinator.handleEventFromOperator(...);
} catch (IllegalArgumentException e) {
  LOG.error("Wrong OperatorEvent sent to TriggerManagerCoordinator", e);
  throw e;
}

Prevention

When it happens

Trigger: A TriggerManagerOperator (or custom operator) sends an OperatorEvent other than LockRegisterEvent to this coordinator, e.g. LockReleaseEvent or a custom event.

Common situations: Custom operators wired into the maintenance job chain sending wrong events; mixing operator versions across a savepoint restore so old code sends events the new coordinator doesn't know; misconfiguration of the operator chain.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors


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