apache/iceberg · error · IllegalArgumentException

Invalid operator event type: <event.getClass().getCanonicalN

Error message

Invalid operator event type: <event.getClass().getCanonicalName()>

What it means

TriggerManagerCoordinator only accepts LockRegisterEvent operator events; any other OperatorEvent delivered to it throws an IllegalArgumentException with the event's class name. This guards the event protocol between trigger operators and their coordinator.

Source

Thrown at flink/v1.20/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. Route LockReleaseEvent to LockRemoverCoordinator and only LockRegisterEvent to TriggerManagerCoordinator.
  2. Check that each operator's OperatorEventGateway belongs to the correct coordinating operator.
  3. If adding new event types, extend the coordinator's instanceof handling first.

Example fix

// before
triggerCoordinatorGateway.sendOperatorEvent(new LockReleaseEvent(taskId));
// after
lockRemoverGateway.sendOperatorEvent(new LockReleaseEvent(taskId));
Defensive patterns

Strategy: type-guard

Validate before calling

if (!(event instanceof LockRegisterEvent)) { throw new IllegalStateException("TriggerManagerCoordinator expects LockRegisterEvent, got " + event.getClass()); }

Type guard

if (event instanceof LockRegisterEvent register) { /* register lock */ }

Try / catch

try { coordinator.handleEventFromOperator(subtask, attempt, event); } catch (IllegalArgumentException e) { LOG.error("Wrong event type for trigger coordinator", e); }

Prevention

When it happens

Trigger: Sending a LockReleaseEvent (or any non-LockRegisterEvent OperatorEvent) to the TriggerManagerCoordinator via handleEventFromOperator.

Common situations: Cross-wiring the maintenance flow: lock-release events (meant for LockRemoverCoordinator) routed to the trigger manager, custom events, or mismatched operator-to-coordinator wiring after refactoring.

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/f05ee95467780fe7. Report an issue: GitHub.