apache/beam · error · UnsupportedOperationException

.isCompatible() should never be called. It is a private…

Error message

%s.isCompatible() should never be called. It is a private implementation detail of sdk utilities. This message indicates a bug in the Beam SDK.

What it means

IdentityWindowFn is a private implementation detail used internally by SDK utilities (e.g. to pass windows through unchanged). Its isCompatible() is deliberately unimplemented: calling it means Beam's internal plumbing invoked a WindowFn that was never meant to participate in window-merging compatibility checks — a genuine SDK bug.

Solutions

  1. Remove user-level use of IdentityWindowFn; it is not a public API — use Window.into()/reassign semantics instead
  2. Report the stack trace to the Beam project (JIRA/GitHub) — the message itself says this indicates a Beam SDK bug
  3. Check for mismatched Beam SDK versions on the classpath (e.g. runner vs SDK) and align them

Example fix

// before
PCollection<T> out = c.apply(new IdentityWindowFn<>(originalWindowFn.windowCoder()));
// after
PCollection<T> out = c.apply(Window.<T>into(originalWindowFn)); // public API, or don't reassign windows at all
Defensive patterns

Strategy: try-catch

Try / catch

try {
  windowFn.isCompatible(other);
} catch (UnsupportedOperationException e) {
  LOG.error("IdentityWindowFn.isCompatible invoked — likely a Beam SDK bug; report stack trace", e);
  throw e;
}

Prevention

When it happens

Trigger: Calling isCompatible() directly on IdentityWindowFn, or pipeline code that requires window-fn compatibility checking across an IdentityWindowFn boundary (e.g. applying it in a user pipeline or combining it with windowing operations the SDK doesn't expect).

Common situations: Users manually constructing IdentityWindowFn in custom transforms; Beam version mismatches where internal utilities changed; custom runners calling isCompatible during stage planning on windows propagated via IdentityWindowFn.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

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

Appendix: source

Thrown at sdks/java/core/src/main/java/org/apache/beam/sdk/util/IdentityWindowFn.java:73

  public IdentityWindowFn(Coder<? extends BoundedWindow> coder) {
    // Safe because it is only used privately here.
    // At every point where a window is returned or accepted, it has been provided
    // by the prior WindowFn, so it is of the expected type.
    @SuppressWarnings("unchecked")
    Coder<BoundedWindow> windowCoder = (Coder<BoundedWindow>) coder;
    this.coder = windowCoder;
  }

  @Override
  public Collection<BoundedWindow> assignWindows(WindowFn<T, BoundedWindow>.AssignContext c)
      throws Exception {
    // The window is provided by the prior WindowFn, which also provides the coder for them
    return Collections.singleton(c.window());
  }

  @Override
  public boolean isCompatible(WindowFn<?, ?> other) {
    throw new UnsupportedOperationException(
        String.format(
            "%s.isCompatible() should never be called."
                + " It is a private implementation detail of sdk utilities."
                + " This message indicates a bug in the Beam SDK.",
            getClass().getCanonicalName()));
  }

  @Override
  public void verifyCompatibility(WindowFn<?, ?> other) throws IncompatibleWindowException {
    throw new UnsupportedOperationException(
        String.format(
            "%s.verifyCompatibility() should never be called."
                + " It is a private implementation detail of sdk utilities."
                + " This message indicates a bug in the Beam SDK.",
            getClass().getCanonicalName()));
  }

  @Override

View on GitHub (pinned to 12126d8942)