What causes "[%s] is not supported in BIT_OR" in apache/beam?

Cast the column to BIGINT/INT64 in the SQL query: SELECT BIT_OR(CAST(flags AS BIGINT)) ...

apache/beam · error · UnsupportedOperationException

[ ] is not supported in BIT_OR

Error message

[%s] is not supported in BIT_OR

What it means

createBitOr implements the BIT_OR aggregate, which is only defined for INT64 fields: if fieldType's TypeName is INT64 it returns the BitOr CombineFn, otherwise it unconditionally throws UnsupportedOperationException. There is no switch/default — any non-INT64 type fails immediately.

Solutions

Cast the column to BIGINT/INT64 in the SQL query: SELECT BIT_OR(CAST(flags AS BIGINT)) ...
Change the schema so the column is declared INT64.
Write a custom CombineFn performing bitwise OR for the narrower integer width and register it.

Example fix

// before
CombineFn fn = BeamBuiltinAggregations.createBitOr(Schema.FieldType.INT32); // throws

// after
CombineFn fn = BeamBuiltinAggregations.createBitOr(Schema.FieldType.INT64);
// SQL: SELECT BIT_OR(CAST(flags AS BIGINT)) FROM t

Defensive patterns

Strategy: validation

Validate before calling

if (fieldType.getTypeName() != Schema.TypeName.INT64) {
  throw new IllegalArgumentException("BIT_OR requires INT64, got " + fieldType);
}

Type guard

boolean bitOpSupported(Schema.FieldType t) {
  return t.getTypeName() == Schema.TypeName.INT64;
}

Try / catch

try {
  CombineFn fn = BeamBuiltinAggregations.createBitOr(fieldType);
} catch (UnsupportedOperationException e) {
  // re-plan with CAST(col AS BIGINT) or custom int-width combiner
}

Prevention

Declare bitmask columns as INT64/BIGINT in Beam schemas.
Always CAST narrower integers to BIGINT before BIT_OR/BIT_AND/BIT_XOR.
Remember only INT64 is accepted — even INT32 fails.

When it happens

Trigger: Calling BeamBuiltinAggregations.createBitOr(fieldType) with any TypeName other than INT64 — e.g. SELECT BIT_OR(int32_col) where the column is INTEGER (INT32) rather than INT64, or a string/boolean column.

Common situations: BIT_OR over an INT32 column is the classic hit: users assume all integer widths work, but only INT64 does; also BIT_OR over string-stored flags.

Related errors

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

Appendix: source

Thrown at sdks/java/extensions/sql/src/main/java/org/apache/beam/sdk/extensions/sql/impl/transform/BeamBuiltinAggregations.java:236

      case INT64:
        return new LongAvg();
      case FLOAT:
        return new FloatAvg();
      case DOUBLE:
        return new DoubleAvg();
      case DECIMAL:
        return new BigDecimalAvg();
      default:
        throw new UnsupportedOperationException(
            String.format("[%s] is not supported in AVG", fieldType));
    }
  }

  static CombineFn createBitOr(Schema.FieldType fieldType) {
    if (fieldType.getTypeName() == TypeName.INT64) {
      return new BitOr();
    }
    throw new UnsupportedOperationException(
        String.format("[%s] is not supported in BIT_OR", fieldType));
  }

  static CombineFn createBitAnd(Schema.FieldType fieldType) {
    if (fieldType.getTypeName() == TypeName.INT64) {
      return new BitAnd();
    }
    throw new UnsupportedOperationException(
        String.format("[%s] is not supported in BIT_AND", fieldType));
  }

  public static CombineFn createBitXOr(Schema.FieldType fieldType) {
    if (fieldType.getTypeName() == TypeName.INT64) {
      return new BitXOr();
    }
    throw new UnsupportedOperationException(
        String.format("[%s] is not supported in BIT_XOR", fieldType));
  }

View on GitHub (pinned to 12126d8942)