apache/beam · error · Error

Unsupported window mapping fn: ${sideInput.windowMappingFn.u

Error message

Unsupported window mapping fn: ${sideInput.windowMappingFn.urn}

What it means

When building side-input metadata in createSideInputInfo, the worker maps the side input's windowMappingFn URN to a JS function (e.g. global window or identity). Any other URN is rejected with this Error because the worker cannot translate that window-mapping behavior.

Source

Thrown at sdks/typescript/src/apache_beam/worker/pardo_context.ts:218

export function createSideInputInfo(
  transformProto: runnerApi.PTransform,
  spec: runnerApi.ParDoPayload,
  operatorContext: operators.OperatorContext,
): Map<string, SideInputInfo> {
  const globalWindow = new GlobalWindow();
  const sideInputInfo: Map<string, SideInputInfo> = new Map();
  for (const [sideInputId, sideInput] of Object.entries(spec.sideInputs)) {
    let windowMappingFn: (window: Window) => Window;
    switch (sideInput.windowMappingFn!.urn) {
      case urns.GLOBAL_WINDOW_MAPPING_FN_URN:
        windowMappingFn = (window) => globalWindow;
        break;
      case urns.IDENTITY_WINDOW_MAPPING_FN_URN:
        windowMappingFn = (window) => window;
        break;
      default:
        throw new Error(
          "Unsupported window mapping fn: " + sideInput.windowMappingFn!.urn,
        );
    }
    const sidePColl =
      operatorContext.descriptor.pcollections[
        transformProto.inputs[sideInputId]
      ];
    const windowingStrategy =
      operatorContext.pipelineContext.getWindowingStrategy(
        sidePColl.windowingStrategyId,
      );
    sideInputInfo.set(sideInputId, {
      elementCoder: operatorContext.pipelineContext.getCoder(sidePColl.coderId),
      windowCoder: operatorContext.pipelineContext.getCoder(
        windowingStrategy.windowCoderId,
      ),
      windowMappingFn: windowMappingFn,
    });

View on GitHub (pinned to 12126d8942)

Solutions

1. Restructure the pipeline so the side input uses a global-window or identity window mapping fn.
2. Pre-materialize the side input with the desired windowing applied upstream (e.g. via a View or re-windowing step) instead of relying on a custom mapping fn.
3. Upgrade the worker if a newer release added support for that URN.
4. Run the affected transform on a runtime that supports the mapping fn (e.g. the Java/Python worker).

Example fix

// before
// pcoll | beam.Map(lambda x, side: ..., side=AsDictionary(pcoll_with_custom_window_mapping))
// after
// use identity or default global mapping, or re-window the side input upstream to globalWindow

// before building the pipeline graph, inspect side input specs
for (const si of sideInputs) {
  const urn = si.windowMappingFn?.urn;
  if (urn && ![GLOBAL_WINDOW_URN, IDENTITY_WINDOW_MAPPING_FN_URN].includes(urn)) {
    throw new Error(`Unsupported side-input mapping ${urn}; re-window upstream`);
  }
}

When it happens

Trigger: A pipeline declares a side input whose windowMappingFn URN is neither the global-window nor identity URN (e.g. a custom or SDK-side mapping function like windows-into-days) consumed by a DoFn running on this TypeScript worker.

Common situations: Using side inputs with non-global window mappings in a pipeline executed by the TS worker; submitting a job built by a Python/Java SDK whose windowing mapping functions the TS worker doesn't support.

Related errors

• %s.getSideInputWindow() should never be called. It is a priv
• failed to map main input window to side input window with Wi
• Unknown context parameter: ${param.parDoParamName}
• Unimplemented access pattern: ${accessPattern}
• State stream is closed.

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