apache/beam · error · Error

Unimplemented access pattern: ${accessPattern}

Error message

Unimplemented access pattern: ${accessPattern}

What it means

createStateKey builds a Fn API StateKey for a state cell given its access pattern (BAG, MULTIMAP, etc.). An unrecognized accessPattern falls through to a default that throws this Error — the TypeScript worker does not implement state access for that pattern.

Source

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

  const writer = new protobufjs.Writer();
  windowCoder.encode(window, writer, CoderContext.needsDelimiters);
  const encodedWindow = writer.finish();

  switch (accessPattern) {
    case "beam:side_input:iterable:v1":
      return {
        type: {
          oneofKind: "iterableSideInput",
          iterableSideInput: {
            transformId: transformId,
            sideInputId: sideInputId,
            window: encodedWindow,
          },
        },
      };

    default:
      throw new Error("Unimplemented access pattern: " + accessPattern);
  }
}

View on GitHub (pinned to 12126d8942)

Solutions

  1. Upgrade the TypeScript worker to a build implementing the access pattern.
  2. Replace the DoFn state cell with a supported access pattern (e.g. BagState) in user code.
  3. Inspect the StateSpec to confirm the access pattern and open/track a Beam issue if it should be supported.

Example fix

// before
// self.state = beam.pvalue.AsBag? -> uses unsupported ORDERED_LIST access pattern
// after
// declare the cell as BagState (read_iterable/write) which the TS worker implements
Defensive patterns

Strategy: validation

Validate before calling

// verify state spec access pattern before wiring user state
const supported = new Set(['BAG', 'MULTIMAP']);
if (stateSpec.accessPattern && !supported.has(stateSpec.accessPattern)) {
  throw new Error(`Precheck: access pattern ${stateSpec.accessPattern} not implemented in TS worker`);
}

Prevention

When it happens

Trigger: DoFn state cell declares an access pattern the worker's createStateKey switch doesn't cover (only bag/multimap-style patterns are implemented); usually from a newer SDK spec or an exotic state family.

Common situations: User state features (orderly list, SetState, or new state types) added in a recent Beam release used with an older TS worker.

Related errors


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