What causes "Cannot infer coder for type parameter " in apache/beam?

Parameterize the subclass with concrete types, e.g. class MyFn extends DoFn instead of raw/generic subclass

apache/beam · error · CannotProvideCoderException

Cannot infer coder for type parameter

Error message

Cannot infer coder for type parameter

What it means

CoderRegistry.getParamCoder (reached via getCoder) tries to map a generic type parameter (e.g. OutputT on a DoFn's ProcessElement) to a concrete coder from previously inferred coders. When the type parameter has no matching inferred entry — usually because the subclass did not parameterize the base class with a concrete type — it throws CannotProvideCoderException 'Cannot infer coder for type parameter'.

Source

Thrown at sdks/java/core/src/main/java/org/apache/beam/sdk/coders/CoderRegistry.java:334

   *     this functionality is refined.
   */
  @Deprecated
  @Internal
  public <T, OutputT> Coder<OutputT> getCoder(
      Class<? extends T> subClass,
      Class<T> baseClass,
      Map<Type, ? extends Coder<?>> knownCoders,
      TypeVariable<?> param)
      throws CannotProvideCoderException {

    Map<Type, Coder<?>> inferredCoders = getDefaultCoders(subClass, baseClass, knownCoders);

    @SuppressWarnings("unchecked")
    Coder<OutputT> paramCoderOrNull = (Coder<OutputT>) inferredCoders.get(param);
    if (paramCoderOrNull != null) {
      return paramCoderOrNull;
    } else {
      throw new CannotProvideCoderException("Cannot infer coder for type parameter " + param);
    }
  }

  /////////////////////////////////////////////////////////////////////////////

  /**
   * Returns a {@code Map} from each of {@code baseClass}'s type parameters to the {@link Coder} to
   * use for it, in the context of {@code subClass}'s specialization of {@code baseClass}.
   *
   * <p>If no {@link Coder} can be inferred for a particular type parameter, then that type variable
   * will be absent from the returned {@code Map}.
   *
   * <p>For example, if {@code baseClass} is {@code Map.class}, where {@code Map<K, V>} has type
   * parameters {@code K} and {@code V}, and {@code subClass} extends {@code Map<String, Integer>}
   * then the result will map the type variable {@code K} to a {@code Coder<String>} and the type
   * variable {@code V} to a {@code Coder<Integer>}.
   *
   * <p>The {@code knownCoders} parameter can be used to provide known {@link Coder Coders} for any

View on GitHub (pinned to 12126d8942)

Solutions

Parameterize the subclass with concrete types, e.g. class MyFn extends DoFn<String, String> instead of raw/generic subclass
Provide the coder explicitly via .setCoder(...) or by overriding getOutputCoder/getDefaultOutputCoder
Use TypeDescriptor supplies at transform calls (e.g. apply(..., new TypeDescriptor<Map<K,V>>() {})) so inference has a concrete type
Check the call site (getOutputCoder, getAccumulatorCoder, bazCoder, fooCoder) for where the type parameter was expected to be bound

Example fix

// before
class MyFn<T> extends DoFn<T, T> { ... } // cannot infer coder for T
// after
class MyFn extends DoFn<String, String> { ... }

Defensive patterns

Strategy: type-guard

Validate before calling

Type sup = TypeDescriptor.of(subClass).getSupertype(DoFn.class).getType();
boolean concrete = !(sup instanceof TypeVariable);

Type guard

boolean isGenericBound = !(TypeDescriptor.of(fn.getClass()).getSupertype(DoFn.class).getType() instanceof TypeVariable);

Try / catch

try {
  coder = registry.getOutputCoder(fn, inputType);
} catch (CannotProvideCoderException e) {
  coder = defaultCoderForMyType;
}

Prevention

Never subclass DoFn/CombineFn with bare type variables; always use concrete type arguments
Avoid anonymous generic classes where type args cannot be resolved; use named concrete subclasses
Override getDefaultOutputCoder when inference would be ambiguous

When it happens

Trigger: Using a DoFn/subclass with a bare type variable (e.g. class MyFn<T> extends DoFn<T, T>) instead of a concrete parameterization (class MyFn extends DoFn<String, String>); calling getOutputCoder/getDefaultOutputCoder on a class whose type arguments are still unresolved type variables.

Common situations: Anonymous subclasses or lambdas without a resolvable generic signature; helper generic classes wrapping DoFns; superclass is generic and instantiated without type args so TypeDescriptor inference yields T.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors

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