apache/beam · error

unexpected input kind

Error message

unexpected input kind: %v

What it means

addMultiEdge encountered a graph edge whose input kind does not map to any known URN case when building the multi-input FunctionSpec for a ParDo-like transform. Only CoGBK, Windowed and similar known kinds are handled; anything else hits the default branch and the marshaller refuses to continue rather than emit a wrong proto.

Solutions

  1. Inspect the edge printed in the error and its InputKind
  2. Use supported combinators (beam.ParDo, beam.CoGroupByKey, beam.WindowInto) instead of hand-built edges
  3. Upgrade or downgrade the SDK to a version where the edge kind is supported
  4. File an issue with Beam if a standard combinator triggers it

Example fix

// before: hand-built edge with unknown kind
edge := graph.Edge{Input: graph.MainUnknown}
// after: build via public API
out := beam.ParDo(p, fn, in)
Defensive patterns

Strategy: validation

Validate before calling

// Before marshalling, walk the graph and assert every edge input kind is supported
for _, e := range g.Edges {
    if !supportedInputKinds[e.Input.Kind] {
        return fmt.Errorf("edge %s has unsupported input kind %v", e.Name, e.Input.Kind)
    }
}

Type guard

func isSupportedKind(k graph.InputKind) bool {
    switch k {
    case graph.Main, graph.CoGBK, graph.Windowed:
        return true
    }
    return false
}

Try / catch

if _, err := graphx.Marshal(p); err != nil {
    if strings.Contains(err.Error(), "unexpected input kind") {
        return fmt.Errorf("pipeline uses unsupported edge construction: %v", err)
    }
    return err
}

Prevention

When it happens

Trigger: Marshalling a pipeline whose transform edge has an unexpected InputKind — typically an internal inconsistency in the constructed graph, or a manually-built graph with an unhandled edge type.

Common situations: Hand-assembling graph.Edge objects in tests or custom code with kinds the translator doesn't support; SDK-internal bugs after upgrading where new edge kinds aren't handled.

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


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

Appendix: source

Thrown at sdks/go/pkg/beam/core/runtime/graphx/translate.go:478

				siWSpec, err := makeWindowFn(siWfn)
				if err != nil {
					return nil, err
				}

				si[fmt.Sprintf("i%v", i)] = &pipepb.SideInput{
					AccessPattern: &pipepb.FunctionSpec{
						Urn: URNMultimapSideInput,
					},
					ViewFn: &pipepb.FunctionSpec{
						Urn: "foo",
					},
					WindowMappingFn: &pipepb.FunctionSpec{
						Urn:     mappingUrn,
						Payload: siWSpec.Payload,
					},
				}
			default:
				return nil, errors.Errorf("unexpected input kind: %v", edge)
			}
		}

		mustEncodeMultiEdge, err := mustEncodeMultiEdgeBase64(edge.Edge)
		if err != nil {
			return handleErr(err)
		}

		payload := &pipepb.ParDoPayload{
			DoFn: &pipepb.FunctionSpec{
				Urn:     URNDoFn,
				Payload: []byte(mustEncodeMultiEdge),
			},
			SideInputs: si,
		}
		if edge.Edge.DoFn.IsSplittable() {
			coderID, err := m.coders.Add(edge.Edge.RestrictionCoder)
			if err != nil {

View on GitHub (pinned to 12126d8942)