apache/beam · error · UnsupportedOperationException

BoundedWindow unsupported in %s

Error message

BoundedWindow unsupported in %s

What it means

window() throws UnsupportedOperationException because the invoker implementation has no BoundedWindow provider bound. It is normally available in windowed contexts (ProcessElement/OnWindowExpiration with window parameter). The error context in the message identifies the invoker lacking support.

Source

Thrown at sdks/java/core/src/main/java/org/apache/beam/sdk/transforms/reflect/DoFnInvoker.java:420

      throw new UnsupportedOperationException(
          String.format("MultiOutputReceiver unsupported in %s", getErrorContext()));
    }

    @Override
    public Object restriction() {
      throw new UnsupportedOperationException(
          String.format("Restriction unsupported in %s", getErrorContext()));
    }

    @Override
    public BoundedWindow window() {
      throw new UnsupportedOperationException(
          String.format("BoundedWindow unsupported in %s", getErrorContext()));
    }

    @Override
    public PaneInfo paneInfo(DoFn<InputT, OutputT> doFn) {
      throw new UnsupportedOperationException(
          String.format("PaneInfo unsupported in %s", getErrorContext()));
    }

    @Override
    public PipelineOptions pipelineOptions() {
      throw new UnsupportedOperationException(
          String.format("PipelineOptions unsupported in %s", getErrorContext()));
    }

    @Override
    public DoFn<InputT, OutputT>.StartBundleContext startBundleContext(DoFn<InputT, OutputT> doFn) {
      throw new UnsupportedOperationException(
          String.format("StartBundleContext unsupported in %s", getErrorContext()));
    }

    @Override
    public DoFn<InputT, OutputT>.FinishBundleContext finishBundleContext(
        DoFn<InputT, OutputT> doFn) {

View on GitHub (pinned to 12126d8942)

Solutions

1. Request the window via the method signature (BoundedWindow parameter) so the runner supplies it
2. Bind a window factory when constructing the invoker
3. Use a runner/DoFnTester version that populates window context
4. Guard c.window() behind instanceof checks when invoking in custom code

Example fix

// before
BoundedWindow w = context.window(); // may throw
// after
@ProcessElement
public void process(ProcessContext c, BoundedWindow window) { /* use window */ }

boolean windowed = context instanceof DoFn.WindowedContext;

if (!(context instanceof DoFn.WindowedContext)) return null; BoundedWindow w = context.window();

try { BoundedWindow w = invoker.window(doFn); } catch (UnsupportedOperationException e) { w = null; }

When it happens

Trigger: Calling invoker.window(doFn) (or a context resolving the window) on a DelegatingDoFnInvoker / generated invoker without a windowFactory; DoFn code calling c.window() when the runner didn't supply window info.

Common situations: Streaming/windowed DoFn code executed in a non-windowed test harness; custom invoker wiring that omits window suppliers; runners that do not expose BoundedWindow in the context.

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

• Distinct does not support merging windowing strategies, exce
• PaneInfo unsupported in %s
• Runner does not support draining.
• Unknown DirectoryTreatment: " + directoryTreatment
• Support for move options is not yet implemented.

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