apache/beam · error · IncompatibleWindowException

Only %s objects with the same window supplier are compatible

Error message

Only %s objects with the same window supplier are compatible.

What it means

StaticWindows.verifyCompatibility() throws IncompatibleWindowException when comparing two StaticWindows window FIFOs that were not created from the same window supplier. Beam's window-fn compatibility check requires StaticWindows instances to originate from the same windowing setup.

Source

Thrown at sdks/java/core/src/main/java/org/apache/beam/sdk/testing/StaticWindows.java:102

      return Collections.singleton(c.window());
    } else {
      return getWindows();
    }
  }

  @Override
  public boolean isCompatible(WindowFn<?, ?> other) {
    if (!(other instanceof StaticWindows)) {
      return false;
    }
    StaticWindows that = (StaticWindows) other;
    return Iterables.elementsEqual(this.windows.get(), that.windows.get());
  }

  @Override
  public void verifyCompatibility(WindowFn<?, ?> other) throws IncompatibleWindowException {
    if (!this.isCompatible(other)) {
      throw new IncompatibleWindowException(
          other,
          String.format(
              "Only %s objects with the same window supplier are compatible.",
              StaticWindows.class.getSimpleName()));
    }
  }

  @Override
  public Coder<BoundedWindow> windowCoder() {
    return coder;
  }

  @Override
  public WindowMappingFn<BoundedWindow> getDefaultWindowMappingFn() {
    return new WindowMappingFn<BoundedWindow>(Duration.millis(Long.MAX_VALUE)) {
      @Override
      public BoundedWindow getSideInputWindow(BoundedWindow mainWindow) {
        checkArgument(

View on GitHub (pinned to 12126d8942)

Solutions

1. Ensure both PCollections use windows produced by the same window supplier/StaticWindows setup.
2. Re-window one of the inputs (e.g. re-apply Window.into() with the same windowing) before combining.
3. If intentional, restructure so incompatible-windowed inputs are not combined.

Example fix

// before
PCollection<A> a = inputA.apply(Window.into(StaticWindows.ofSupplier(supplier1)));
// after
PCollection<A> a = inputA.apply(Window.into(StaticWindows.ofSupplier(sharedSupplier)));

staticWindows1.isCompatible(staticWindows2); // call before combining PCollections

try { pipeline.apply(Flatten.of(a, b)); } catch (IncompatibleWindowException e) { /* re-window inputs with the same supplier */ }

When it happens

Trigger: Combining PCollections windowed with different StaticWindows instances (different window suppliers) in the same transform, triggering window fn compatibility verification during pipeline construction/validation.

Common situations: Merging streams windowed independently in different tests or helper methods; reusing Window.into() results with custom static window setups across pipelines.

Understand the failure class

Background: "is not a compatible type" / "cannot merge" errors: when a value's type doesn't match what the library requires — this error's family across 65 libraries.

Related errors

• ApproximateUnique.PerKey needs an estimation error between 1
• ApproximateUnique.PerKey requires its input to use KvCoder
• Cannot provide coder for elements of Create: For their commo
• Cannot provide coder for elements of Create: For their commo
• numPartitions must be > 0

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