What causes "Types do not match: ${type1}, ${type2}" in apache/beam?

Make both operands the same type, e.g. cast one side or use matching literal forms (1.0 vs 1)

apache/beam · error · IllegalStateException

Types do not match

Error message

Types do not match: ${type1}, ${type2}

What it means

The NFA arithmetic helper requires both operands of a binary operation to have the same Schema.TypeName. When type1 != type2 it throws IllegalStateException listing both types, because the implementation has no implicit coercion between literal types.

Solutions

Make both operands the same type, e.g. cast one side or use matching literal forms (1.0 vs 1)
Declare/adjust the column schema so related columns share a numeric type
Check both operand types at query-construction time before running the CEP query

Example fix

// before
DEFINE e AS PRICE + 1 -- PRICE is DOUBLE, 1 is INTEGER
// after
DEFINE e AS PRICE + 1.0

Defensive patterns

Strategy: validation

Validate before calling

if (type1 != type2) {
  throw new IllegalArgumentException("CEP arithmetic operands must share a type: " + type1 + " vs " + type2);
}

Type guard

boolean sameNumericType(Schema.TypeName a, Schema.TypeName b) {
  return a == b;
}

Try / catch

try {
  runCepQuery(pattern);
} catch (IllegalStateException e) {
  if (e.getMessage().startsWith("Types do not match:")) {
    // align operand types (cast or adjust literals) and retry
  } else throw e;
}

Prevention

Match literal forms to column types (1.0 for DOUBLE/DECIMAL columns, 1 for INTEGER)
Keep the input schema stable; update pattern expressions when column types change
Prefer a single numeric type across a pattern's DEFINE expressions

When it happens

Trigger: An arithmetic operation in a DEFINE clause mixes operand types, e.g. DECIMAL + DOUBLE or INTEGER + DECIMAL literals/columns.

Common situations: Comparing/adding an integer column to a decimal literal; schema evolution changing a column type so pattern expressions no longer line up.

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/7f768c2c83dd93ea. Report an issue: GitHub.

Appendix: source

Thrown at sdks/java/extensions/sql/src/main/java/org/apache/beam/sdk/extensions/sql/impl/nfa/NFA.java:639

          case BYTE:
            return CEPLiteral.of(opr1.getByte() + opr2.getByte());
          case INT16:
            return CEPLiteral.of(opr1.getInt16() + opr2.getInt16());
          case INT32:
            return CEPLiteral.of(opr1.getInt32() + opr2.getInt32());
          case INT64:
            return CEPLiteral.of(opr1.getInt64() + opr2.getInt64());
          case DECIMAL:
            return CEPLiteral.of(opr1.getDecimal().add(opr2.getDecimal()));
          case FLOAT:
            return CEPLiteral.of(opr1.getFloat() + opr2.getFloat());
          case DOUBLE:
            return CEPLiteral.of(opr1.getDouble() + opr2.getDouble());
          default:
            throw new UnsupportedOperationException("Type is not supported: " + type1.toString());
        }
      } else {
        throw new IllegalStateException(
            "Types do not match: " + type1.toString() + ", " + type2.toString());
      }
    }
  }

  // State are determined directly by the PATTERN clause
  private static class State implements Serializable {
    private int index = 0; // number ith state (pointer value) in the NFA
    private final String patternVar;
    private final Quantifier quant;
    private final CEPOperation
        condition; // condition to evaluate when taking the "begin" action and "proceed" action
    private State nextState = null;
    public final boolean isFinal;
    private final boolean
        isKleenePlusSecondary; // whether is the second state for a Kleene Plus pattern variable

    State(

View on GitHub (pinned to 12126d8942)