apache/beam · error

local input (global ) uses accesspattern

Error message

local input %v (global %v) uses accesspattern %v

What it means

Side inputs are resolved by their declared AccessPattern. Prism supports the default (materialized multimap / LIST) access patterns; any other pattern hits the default case and returns this error identifying the local input, global PCollection, and unrecognized AccessPattern proto. It means the transform requests a side input access strategy prism does not implement.

Solutions

1. Upgrade prism/beam runner version that supports the access pattern URN
2. Restructure the pipeline to use standard map/multimap side inputs
3. Avoid cross-language side input views; pass data as main inputs instead
4. Log the full prototext AccessPattern from the message to identify the unsupported URN

Example fix

// before: Python SDK view AsIter side input consumed by Go prism stage
// after: use AsDict/AsMap style materialized side input or restructure as main input

// Check the access pattern URN is one prism supports before submit
urn := si.GetAccessPattern().GetUrn()
if urn != "beam:sideinput:multimap:v1" && urn != "beam:protocol:runner:v1" {
    return fmt.Errorf("unsupported side input access pattern: %s", urn)
}

err := job.Submit(ctx)
if err != nil && strings.Contains(err.Error(), "uses accesspattern") {
    log.Printf("unsupported side input access pattern, restructuring pipeline")
    return runWithMainInputInstead(p)
}

When it happens

Trigger: A ParDo's environment/inputs declare an AccessPattern URN outside the known cases in handleSideInput's switch (neither urns.InputMultimap nor the materialized/default pattern).

Common situations: Cross-language transforms (Python/Java) requesting view or iterable access patterns prism hasn't implemented; newer Beam SDK URNs not yet supported by the installed runner; custom environments declaring exotic access patterns.

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

• buildDescriptor: failed to handle coder on stage
• multimap side inputs needs KV coder, got
• stage[ ] no parent for side input , with parent ID
• stage[ ] no parent ID for side input
• A cannot be expanded

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

Appendix: source

Thrown at sdks/go/pkg/beam/runners/prism/internal/stage.go:769

			for win, ds := range data {
				if len(ds) == 0 {
					continue
				}
				byKey := map[string][][]byte{}
				for _, datum := range ds {
					r := bytes.NewBuffer(datum)
					kb := kd(r)
					byKey[string(kb)] = append(byKey[string(kb)], vd(r))
				}
				windowed[win] = byKey
			}
			b.MultiMapSideInputData[worker.SideInputKey{
				TransformID: link.Transform,
				Local:       link.Local,
			}] = windowed
		}, nil
	default:
		return nil, fmt.Errorf("local input %v (global %v) uses accesspattern %v", link.Local, link.Global, prototext.Format(si.GetAccessPattern()))
	}
}

func sourceTransform(parentID string, sourcePortBytes []byte, outPID string) *pipepb.PTransform {
	source := &pipepb.PTransform{
		UniqueName: parentID,
		Spec: &pipepb.FunctionSpec{
			Urn:     urns.TransformSource,
			Payload: sourcePortBytes,
		},
		Outputs: map[string]string{
			"i0": outPID,
		},
	}
	return source
}

func sinkTransform(sinkID string, sinkPortBytes []byte, inPID string) *pipepb.PTransform {

View on GitHub (pinned to 12126d8942)